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

[Guido van Rossum]

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