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

Guido van Rossum guido at python.org
Tue Apr 24 21:00:59 CEST 2007

Let's agree to disagree. I am getting tired from going around in circles about this.

On 4/24/07, Phillip J. Eby <pje at telecommunity.com> wrote:

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.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list