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

[Phillip J. Eby]

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.  :)

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

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.


>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.