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

Jim Jewett jimjjewett at gmail.com
Mon Apr 23 22:52:57 CEST 2007

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

More information about the Python-3000 mailing list