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

Phillip J. Eby pje at telecommunity.com
Tue Apr 24 13:51:47 CEST 2007

At 09:25 PM 4/23/2007 -0700, Guido van Rossum wrote:

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.

Right - but as I understand it, Java and C# allow a class to be abstract without having any of its methods being abstract. I wasn't proposing that a redudnant class level @abstract be required; just noting that it seems useful to declare a class @abstract regardless of whether it has any abstract methods.

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

Well, by my definition of "abstract", none of the ABCs in the sandbox have any abstract methods (i.e. methods without a usable implementation), so apparently you do see the point. We just have different definitions of "abstract". :)

Mine (courtesy of other languages) is, "a method without an implementation". Yours appears to be "a method that must be overridden". An abstract class, to me, is simply one that is not instantiable. Is that your definition as well?

(By the way, I'm not continuing this thread to push for my definitions -- I'm seeking clarity so that your PEP can better explain just what it is that you mean to do. E.g. "While in other languages, abstract methods are X, Python abstract methods are Y". I'm clear now about what the behavior of Y is, but am trying to understand the reasons of Y.)

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.

But "b", as far as I can tell, doesn't have anything to do with abstractness as I understand it. If there's a useful end-point, why does it need to be abstract? What do we gain by making someone override it? It seems like making somebody jump through a Java-style typechecking hoop for no purpose. ISTM that "consenting adults" means I should be able to just use that code without overriding it, as long as there is something there to use.

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.

Of course not -- but those differences are something you're not likely to miss by skimming the docs! ;) My point here is to make sure that this gets called out clearly and boldly, since it is a Python-only concept that nonetheless is using a term that means something completely different in other languages. We might, perhaps, consider an alternative term for it than 'abstractmethod', since it is quite different from what anybody else means by "abstract method", as far as I can tell.

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

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.

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.

Right; so let's work on making the rationale for it a bit clearer. (i.e., I've already stopped arguing to change the behavior -- I just want to understand it better.)

More information about the Python-3000 mailing list