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

[Jim Jewett]

On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 11:43 AM 4/23/2007 -0700, Guido van Rossum wrote:
> >On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:

> > >    @abstract
> > >    def spam(fizz):
> > >        """This function has no default implementation, and raises
> > >           a "no applicable methods" error if called..."""

> >(a) What's the point of having a separate keyword for this, as
> >opposed to just raising an exception from the body?

> EIBTI, mainly.  Specifically, it's clear from the beginning that you're
> looking at an empty function -- i.e., one that *can't* be called
> successfully except for explicitly registered patterns -- versus one that
> has a truly "generic" base implementation.

erm... not to me.  To me it looks like any short function until I look
carefully.  Once I do notice that the function body is only a string,
I get a bad reaction, until I remember that is is really just a
strange abbreviation for "pass".

> I believe there was also another, somewhat more esoteric
> reason that gets involved when you build more sophisticated
> rulesystems on top of the base machinery, but the exact reason
> is escaping me at this moment. ... sort
> of like doing math without being able to write "zero":

I think it had to do with next_method, and was the same problem super
has.  If you aren't sure the job is done -- no matter what you got
mixed with -- then you have to call the next method.  99% of the time,
it won't do anything useful, but you have to call it just in case.

My favorite example is __del__(), or at least close().  I can be sure
that I've cleaned up *my* scarce resources, but I don't know what
subclasses might have mixed me in with.  So I call super  __del__, and
catch the Exception when it turns out I wasn't mixed in at all.

A "pass" default implementation is much nicer to subclasses than an
Exception that they have to try...except.

> > My point is, I could rename mine to @abstract so that it
> >would serve your purpose as well -- but only if it would serve.

> Assuming that:

> 1.  If you call such a function, it will raise some error, like
> NotImplementedError

Note that your default methods don't do this either, except as part of
the wrapper.  Guido's current implementation is that

    (a)  An error is raised as soon as you try to instantiate a class
that *could* call the method directly, even if you don't plan to ever
*actually* call it.

    (b)  The method itself is annotated, so that the rules engine
could raise an error if it so chose.

> 2.  It's a normal function object (i.e., can have its func_code
> repointed later)
> 3.  The __isabstractmethod__ can be set back to False once there
> is other code registered

I'm not sure that actually *doing* this would play well with ABC
assumptions, but, yes, it is possible.

> Then yes, it's perfect.

-jJ