[Python-3000] Generic function PEP won't make it in time (original) (raw)

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:

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.

More information about the Python-3000 mailing list