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

[Guido van Rossum]

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/)