Native Interface Support in Python

Dear Python Community,

I would like to propose the addition of native interface support in Python to enhance code clarity, enforce contracts, and facilitate the implementation of design patterns. The introduction of interfaces as a language feature would not only improve the maintainability and understandability of Python code but also provide a mechanism for explicitly specifying contracts and multiple interface implementations in a concise and clear manner.

The Need for Interfaces:

Interfaces serve as contracts that define a set of methods and properties that implementing classes must adhere to. They play a crucial role in code design by allowing developers to:

  1. Specify Contracts: With native interfaces, developers can explicitly define contracts for classes, making it clear which methods must be implemented. This helps in designing robust software and reduces the risk of unintentional omissions.
  2. Improve Code Readability: Native interfaces provide a clear and standardized way to convey the intended behavior of classes. This enhances code readability and reduces the need for excessive documentation.
  3. Enforce Design Patterns: Interfaces are a fundamental part of many design patterns, such as the Strategy Pattern or Observer Pattern. With native interface support, these patterns can be implemented more effectively and intuitively.

Proposed Interface Syntax:

We propose introducing a concise and readable syntax for declaring interfaces and implementing them:

pythonCopy code

# Declare an interface
interface MyInterface:
    def firstMethod()
    def methodWithTypedReturn() -> int

# Implement an interface
class MyInterfaceImplementation(MyInterface):
    def firstMethod():
    def methodWithTypedReturn() -> int:

Multiple Interface Implementation:

Python should support the implementation of multiple interfaces in a single class, allowing for easy aggregation of methods from various interfaces:

pythonCopy code

interface MyFirstInterface:
    def firstMethod()
    def secondMethod()

interface MySecondInterface:
    def thirdMethod()
    def fourthMethod()

class MyInterfaceImplementation(MyFirstInterface, MySecondInterface):
    def firstMethod():
    def secondMethod():
    def thirdMethod():
    def fourthMethod():

Retrieving Implementations:

A native method to retrieve all implementations of an interface would facilitate working with design patterns and dynamic class discovery:

pythonCopy code

interfaces = implementations(MyFirstInterface)
# interfaces = [MyInterfaceImplementation]

In the evolving landscape of Python development, the introduction of a new implementations() function opens up exciting possibilities for developers to interact with interfaces in a more dynamic and expressive manner. This proposed functionality not only simplifies the retrieval of interface implementations but also empowers developers to filter interfaces based on the methods implemented within the implementing classes.

Understanding implementations():

The implementations() function is designed to facilitate the discovery of classes that implement a particular interface. However, it goes beyond mere identification; it allows for advanced interactions with these implementations, offering developers an elegant and Pythonic way to filter interfaces based on the presence and behavior of specific methods within the implementing classes.

Filtering Interfaces by Implemented Methods:

Consider the following scenario:

pythonCopy code

interface MyInterface:
    def filter(a) -> bool
    def do_something() -> int

class MyClassOne(MyInterface):
    def filter(a):
        return a == 1
    def do_something() -> int:
        return 1

class MyOtherClass(MyInterface):
    def filter(a):
        return a != 1
    def do_something() -> int:
        return 2

result = implementations(MyInterface).filter(1).do_something()
# result = 1

In this example, the implementations() function is not just about identifying classes that implement MyInterface. It allows us to chain methods like filter(1) and do_something() to precisely select an implementing class based on the behavior of its methods. In this case, it chooses MyClassOne because it satisfies both the filter and do_something criteria.

Benefits of the implementations() Function:

  • Simplified Interface Selection: Developers can now succinctly choose an implementing class based on the behavior of its methods, leading to cleaner and more readable code.
  • Dynamic Design Patterns: This functionality enhances the use of design patterns, such as the Strategy Pattern, by making it easier to select and utilize appropriate implementations based on runtime conditions.
  • Reduced Boilerplate Code: With implementations(), developers can avoid writing custom code to discover and filter classes implementing specific interfaces, reducing boilerplate code and enhancing maintainability.

In conclusion, the proposed implementations() function introduces a powerful and versatile feature that simplifies interface interaction and allows for dynamic selection of implementing classes based on their method behavior. This functionality aligns with Python’s philosophy of readability and simplicity, making it a valuable addition to the language’s toolbox.

As Python continues to evolve and adapt to the needs of its diverse user base, the implementations() function represents a step forward in enhancing the language’s expressiveness and flexibility


  • Enhanced Code Quality: Native interfaces ensure that classes conform to expected behaviors, reducing bugs and maintenance efforts.
  • Improved Codebase Clarity: Clearly defined interfaces make the codebase more understandable and self-documenting, which benefits both developers and maintainers.
  • Efficient Design Patterns: Implementing design patterns becomes more intuitive and efficient, leading to cleaner and more maintainable code.

In conclusion, introducing native interface support in Python would align the language with modern software engineering practices, enhancing code quality and readability. This proposal aims to make Python even more versatile and appealing to developers, enabling the creation of robust and maintainable software projects.

We welcome your feedback and look forward to the possibility of making Python an even more powerful language for software development.

Thank you for your consideration.

Sincerely, Marcos Stefani Rosa

Could you clarify how this is different from abstract base classes or protocols?


I could be wrong, but from what I know all interface solutions use classes, thus compromising readability. Another factor would be the possibility of using the implementations of an interface in a functional way, thus enabling different ways of working with design patterns.

Could you describe how interfaces would be used? And in particular, where they could be used that an ABC could not.

You should also describe the readability problems you see with using classes.


Does it really? Your most recent two proposals have this in common: they require new syntax for “readability” when the exact same thing can be done in other ways. Can you show the problems with current ways of doing things, and how dedicated syntax would improve it? Remember that new syntax is expensive. You can’t use it on older versions of Python, which means you can’t use it until you drop support for those versions (whereas libraries can be backported). Tools need to be enhanced to understand them. Depending on how the new syntax is designed, it may cause conflicts with previously-valid code. All of this means there needs to be a strong and compelling reason to create the syntactic version instead of the existing one.

Show us a side-by-side of what can now be done vs what you’d like to do, and show us how much better it is.

1 Like

Yes, these are my only annoyances in Python.

I’m sorry, but I still don’t understand how I would use interfaces. You’ve said it will make things better, but you’ve given no examples or descriptions of how it would work. It’s not possible to evaluate your proposal until you do that.

1 Like

I know that in Python we have people who don’t like these types of changes that I proposed, they prefer to avoid touching the core of the language and I even understand that. However, there comes a time when some changes would add to the language in a significant way. Opening up a range of possibilities. I’m not here to attack anyone, but until I was called a bot I already was. It’s a shame to have that kind of response when you want to bring a different idea. I just want to stop contributing to the language, I don’t know how long to insist.

1 Like

However you completely failed to demonstrate how your proposal makes something better than the already available protocol or abc facilities

Agreed. Multiple people asked how and why is your proposal different from the existing mechanisms. The response:

  • was “readability” without more details on readability aspects are addressed
  • a long description on why coding to an interface (the concept of an API contract) provides benefits compared to coding to an implementation.

I don’t think the ChatGPT comment was the best phrased. But I suspect it was a reaction to a post that felt more like a book description of why is the concept of an interface beneficial when that wasn’t the questions being asked.

Protocol and ABC both provide ways that code can utilize as type annotations to specify that the contract that an object is expected to have without directly depending on a specific implementation. Both of these things already exist. For any proposal to be accepted, at a minimum, it needs to demonstrate that provides capabilities that aren’t currently present or provide a significant improvement over the existing patterns.


In general, my mantra about formal Interfaces is “all they can do is break.”

If you ever want to add something to an Interface, you can’t - it would break every existing implementer.

If you ever want to add something to an implementer, you can’t do that either, at least not if you want consumers to still treat you as that Interface type and not your special subtype.

Other solutions like ABC don’t have this problem, so I’d not be in favor of adding formal Interfaces.

1 Like

Hi! I’m just here because I work with a large codebase which implements interfaces like there was no tomorrow and I hate them with a passion, they do nothing except making debugging more complex, and some people think they write better code by adding interfaces, wrong, its like getters and setters, some people come to work and just write getters and setters and the more advanced version of that is the interfacers, the last thing we need is a built in way of writing them. Also I recognize there theoretically might be a use for them, but I’ve never seen a legitimate interface.

Closing to avoid further resurrection with more “me too” comments. It’s pretty clear the reception was already negative, and it hadn’t been touched in 5 months.