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

[Guido van Rossum]

On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote:
> >>I suppose there is some value in requiring people to override @abstract
> >>methods to make a subclass instantiable, versus merely using the lack of an
> >>@abstract class decorator to indicate that a subclass is concrete.  But I
> >>wonder if being able to have just one @abstract decorator (that always
> >>means "you can't call this by default") mightn't be worth giving up that
> >>tiny bit of extra type checking?
> >
> >I prefer to follow the lead of C++ here -- an abstract class is
> >abstract by virtue of having at least one abstract method.
>
> It's been way too long since I did any C++, but isn't it the case that an
> abstract (aka "pure virtual"?) method in C++ is one that *can't be
> invoked*?  [pause to Google it...]  Well I'll be darned.  I didn't know you
> could actually provide an implementation for a pure virtual
> function.  Hm.  Learn something new every day...  except while I was
> writing C++ evidently.  :)

Actually I just meant to follow its lead in defining that a class is
abstract as soon as one or more of its methods are abstract. In Java
you need to repeat this by making the class abstract; that seems
unpythonic.

> But are there any other languages besides C++ that have this idiom?  I'm
> not familiar with any that do (at least, not that I know of!), and the fact
> that C++ allows it seems a bit non-obvious to me.  Java and C# pretty much
> do @abstract the way I proposed it, for example:
>
> Java: http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html
> C#: http://www.codeproject.com/useritems/Abstract_CLS_MTHD.asp
>
> That is, they both separate class-abstraction from method-abstraction, even
> though the latter implies the former.  Thus, you can have an abstract class
> 'Iterator' even if all its methods are non-abstract.  (However, if any of
> its methods are abstract, the class itself is required to be abstract.)

I don't see the point of having an abstract class without abstract methods.

The main reasons I came up (without knowing C++ allows this too!) with
the idea of giving abstract methods a valid implementation wer (a)
there's got to be *something* in the body; (b) to provide an end point
for cooperative-MI-style code.

> As someone with more recent background in Java than C++, I find the idea of
> abstract methods having an executable implementation to be quite confusing,
> and suspect that other people with that Java or C# background will do the
> same thing.  That is, skim the explanation and miss the significant
> difference between the C++ way and what they're used to.

Well, too bad. After a day of coding in Java I start typing curly
braces and semicolons too. But that doesn't mean Python should adopt
these.

> >That the abstract methods are still somewhat useful implementations is
> >mostly to provide a valid (if not necessarily useful) end point for
> >super-calling in cooperative MI schemes.
>
> Right; I guess my point is that if those "somewhat" useful implementations
> are useful, they're useful, and there's no need to treat the corresponding
> class as "abstract" (in the "non-instantiable" sense) in that case.  For
> example, I could pass an Iterable() to something that expected an iterable.

Perhaps. Though I think it would defeat the purpose of being required
to provide an implementation. If forced to choose, I'd rather remove
the meaningful bodies (and replace them with "raise
NotImplementedError") than remove the @abstractmethod decorators. But
I prefer the current proposal.

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