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

[Phillip J. Eby]

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

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.

Assuming that:

1.  If you call such a function, it will raise some error, like 
NotImplementedError
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

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