[Python-3000] Generic function PEP won't make it in time
Phillip J. Eby
pje at telecommunity.com
Tue Apr 24 03:09:53 CEST 2007
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:
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.
More information about the Python-3000