[Python-3000] Generic function PEP won't make it in time (original) (raw)
Guido van Rossum guido at python.org
Thu Apr 26 20:32:33 CEST 2007
- Previous message: [Python-3000] [Python-Dev] call for PEPs
- Next message: [Python-3000] Generic function PEP won't make it in time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4/26/07, Bill Janssen <janssen at parc.com> wrote: [Guido]
> But it makes sense in some cases to insist that someone who goes > through the trouble of inheriting from an ABC gets an error if they > forget to implement one of the methods that are deemed 'essential' to > that ABC.
This is the problem with abstract methods. What should happen is that the default method (the one defined in the ABC class) gets called. Otherwise you're back in the morass of Java types, without effective mixin capability. In Python, we need to be able to define an abstract class with real implementation methods -- a class that both defines an interface, and provides an implementation. That means that anyone providing a subclass need only implement the methods that they override. Now, we can still have a way of marking the methods of an ABC as being "not implemented", which would in fact force the subclass designer to implement them. But this concept should be carefully separated from the concept of "this method is part of the interface defined by this class".
Yeah. I like @abstractmethod to mean "not implemented" (except perhaps as an end point for cooperative super calls). For the latter concept, I propose that all methods present in an apparent ABC are considered part of the interface, unless their name starts with a single underscore (the latter should be considered implementation details, or perhaps definitional details).
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-3000] [Python-Dev] call for PEPs
- Next message: [Python-3000] Generic function PEP won't make it in time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]