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

[Phillip J. Eby]

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