[Python-3000] Generic function PEP won't make it in time (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Apr 24 20:35:10 CEST 2007

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.

More information about the Python-3000 mailing list