[Python-3000] Generic function PEP won't make it in time
Phillip J. Eby
pje at telecommunity.com
Mon Apr 23 21:28:14 CEST 2007
At 11:43 AM 4/23/2007 -0700, Guido van Rossum wrote:
>On 4/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > from overloading import overload, abstract
> > def foo(bar, baz):
> > """Default implementation here"""
> > @overload
> > def foo(bar:int, baz:str):
> > """Overloaded implementation for int/str here"""
> > @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.
For example, a "pprint" generic function whose implementation falls back to
repr() is a bit different than say, a "get_stream()" function that can only
be called on path objects, stringIOs, files, and sockets. The latter has
no "generic" implementation.
Using the decorator also makes it easier to be consistent about what error
is raised -- @abstract is easier for me to remember than which exception to
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. I remember
there being something that bothered me about your original Py3K overloading
prototype having to always use the original function body as the default
condition, but I don't remember specifically what, except that it was sort
of like doing math without being able to write "zero": you can work around
it, but it's kind of weird. :)
>(b) I'm proposing an @abstractmethod, which sets its argument's
>__isabstractmethod__ attribute and then returns it, otherwise
>unchanged. Would this be good enough for you, or do you need @abstract
>to do more? My point is, I could rename mine to @abstract so that it
>would serve your purpose as well -- but only if it would serve.
1. If you call such a function, it will raise some error, like
2. It's a normal function object (i.e., can have its func_code repointed
3. The __isabstractmethod__ can be set back to False once there is other
Then yes, it's perfect.
> > @overload
> > def spam(fizz:list):
> > """...unless an appropriate overload is added first"""
> > Any questions? :)
>I'd like the examples even better if they used ABCs from PEP 3119. :-)
I'll keep that in mind for the actual PEP. :)
More information about the Python-3000