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

Guido van Rossum guido at python.org
Tue Apr 24 19:50:16 CEST 2007

On 4/24/07, Phillip J. Eby <pje at telecommunity.com> wrote:

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.

OK. It's a minor feature, but I have a use case: I've seen code that says

raise Exception("some error message")

and that's really a mistake -- if they are to lazy to define their own exception subclass they should raise RuntimeError() or another appropriate standard error. So if we had this feature I'd make BaseException, Exception, StandardError, EnvironmentError and Warning abstract (or at least the first 2-3 of those).

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

In my definition they are abstract if they have an @abstractmethod decorator. :)

Mine (courtesy of other languages) is, "a method without an implementation". Yours appears to be "a method that must be overridden".

That's a very subtle distinction, since the goal in other languages is certainly to force it to be overridden.

An abstract class, to me, is simply one that is not instantiable. Is that your definition as well?

As the PEP stands today it's a class that has at least one abstract method (that isn't overridden).

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

Frankly, I don't care all that much about the reasons -- you can read into it what you want. I am just trying to define mechanisms that I think are useful.

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

It doesn't have to be. Being a useful end-point and being abstract are separate concepts. They are intertwined only because IMO abstract-ness shouldn't prevent something from being a useful end-point. The cooperative-MI theory makes a big distinction between defining and overriding of methods; abstract methods (if not by definition then by convention) are defining new methods, not overriding them, so that pretty much requires them to be useful end-points -- but being an end-point doesn't mean they can't 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.

The only practical concrete use I see of these abstract classes would be to have a handy "empty sequence/set/mapping/iterator/etc." implementation. Since an empty list/set/dict/etc. serves just as well for that purpose I don't think this is a strong use case.

What I'm trying to do with the @abstractmethod decorator is telling potential implementors of these classes: the minimum set of operations you need to provide in order to be an X is this one (or these two or three) methods (the ones that have the @abstractmethod decorator).

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

I don't expect confusion (except from folks who tend to over-analyze things), since the practical consequences are pretty much the same. You could happily ignore the fact that some abstract methods are callable (via super). Remember Python makes a business out of taking concepts and terms from other languages and giving them new meaning. E.g. assignment -> name binding, classes and imports as run-time features, etc. Python's MI is another big one.

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.

What is the point of claiming to be a Sequence without overriding getitem?

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

More information about the Python-3000 mailing list