[Python-3000] Generic function PEP won't make it in time

[Phillip J. Eby]

At 10:50 AM 4/24/2007 -0700, Guido van Rossum wrote:
>On 4/24/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>Mine (courtesy of other languages) is, "a method without an
>>implementation".  Yours appears to be "a method that must be
>>overridden".
>
>That's a very subtle distinction, since the *goal* in other languages
>is certainly to force it to be overridden.

But this just goes right back around to the original point...  if you 
*have* an implementation, you don't really *need* to force it to be 
overridden.  Or do you?

As far as I can tell, you still haven't said what the point of *forcing* 
somebody to override perfectly usable methods is.  You've merely said you 
don't see the point of inheriting or using them directly, but that's not 
the same thing as a rationale for *forcing* them not to.


>Being a useful end-point and being abstract
>are separate concepts.  They are intertwined only because IMO
>abstract-ness shouldn't prevent something from being a useful
>end-point.

But that's the very definition of "abstract" -- i.e., that it's *not* useful.


>The only practical concrete use I see of these abstract classes would
>be to have a handy "empty sequence/set/mapping/iterator/etc."
>implementation. Since an empty list/set/dict/etc. serves just as well
>for that purpose I don't think this is a strong use case.

That's certainly true for the Python-supplied ABCs, but it's not so for 
many other use cases.  I frequently write base classes that have various 
default implementations, combined with a few methods that have to be 
overridden.  On the other hand, specifying which methods


>What I'm *trying* to do with the @abstractmethod decorator is telling
>potential implementors of these classes: the minimum set of operations
>you need to provide in order to be an X is this one (or these two or
>three) methods (the ones that have the @abstractmethod decorator).

Then let's call it @required or @requiredmethod, and all is well.  :)  I've 
just been trying to get clarity on your intent, so I could suggest a name 
that reflects that intent.  At this point, it seems clear your intent is to 
say, "this method is required in a subclass, even if there's an 
implementation here".  So let's have a name that reflects that intention.

(I still don't see the point of marking a method as required if it has an 
actual implementation, since to my way of thinking there is no harm in 
someone *not* overriding it.  They simply don't get as rich of a behavior 
in that case.  But that's a separate issue.)


>>And what *is* the purpose of being required to provide an implementation,
>>if a useful one exists?  This is the bit I guess I'm still missing.
>
>What is the point of claiming to be a Sequence *without* overriding 
>__getitem__?

I didn't say there was a point to that.  However, as Jim Jewett pointed 
out, you can have mutually recursive default implementations of a protocol, 
and probably at least *one* of the methods needs to be overridden.

Really, the patterns of what needs to be overridden in subclasses is 
complex enough that we don't really want to get into a bunch of ways to 
specify how those things should be overridden.  That's why I don't see the 
"make sure you override everything" testing as being all that useful; it 
seems too much like adding empty methods and extra "try" blocks in Java 
just to get your code past the compiler.