[Python-3000] Generic function PEP won't make it in time
Phillip J. Eby
pje at telecommunity.com
Tue Apr 24 01:13:12 CEST 2007
At 03:16 PM 4/23/2007 -0700, Guido van Rossum wrote:
>On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>1. If you call such a function, it will raise some error, like
>That would be up to the author of the function; they would have to
>explicitly raise NotImplementedError in the body. The ABC proposal
>allows meaningful abstract methods that can be called (only) via
>"super"; the use case for this is that the abstract method might be
>the one that decides which exception should be thrown (e.g.
>__getitem__ and __next__ do this), or perhaps it could provide a
>default implementation for certain types. (Potential example of the
>latter: Sequence.__getitem__() could raise IndexError when the
>argument is an Integer but handle the case where the argument is a
>slice instance, assuming there's a suitable factory which could be a
>designated class method.)
Ah... interesting. This is different from what I understood to be
"abstract" methods in other languages where an abstract method is always
one that does not have an actual implementation. I guess I skimmed PEP
3119 a little too quickly.
It sounds like your proposal is to mark methods as "abstract" even if they
have a useful "null" implementation. I guess I don't see what this adds,
at least for the examples in the sandbox, except for making the class
non-instantiable as a side-effect.
Of course, if @abstract were a class decorator as well as a function
decorator, then it could have a single meaning in both contexts: "this
thing shouldn't be callable".
That is to say, this:
would simply mean calling "Iterator()" would result in a
NotImplementedError, just like marking a function @abstract means that
calling it would result in a NotImplementedError.
And, as far as I can see, the only ABC method I'd mark @abstract
individually would be Hashable.__hash__: everything else here looks to me
like a perfectly valid "empty" implementation of the method(s) in question.
I suppose there is some value in requiring people to override @abstract
methods to make a subclass instantiable, versus merely using the lack of an
@abstract class decorator to indicate that a subclass is concrete. But I
wonder if being able to have just one @abstract decorator (that always
means "you can't call this by default") mightn't be worth giving up that
tiny bit of extra type checking?
More information about the Python-3000