[Python-3000] Generic function PEP won't make it in time
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
> >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
> 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
> 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