[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Tue May 1 18:36:17 CEST 2007
At 09:13 AM 5/1/2007 -0700, Talin wrote:
>Phillip J. Eby wrote:
>>Proceeding to the "Next" Method
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>If the first parameter of an overloaded function is named
>>``__proceed__``, it will be passed a callable representing the next
>>most-specific method. For example, this code::
>> def foo(bar:object, baz:object):
>> print "got objects!"
>> @overload
>> def foo(__proceed__, bar:int, baz:int):
>> print "got integers!"
>> return __proceed__(bar, baz)
>
>I don't care for the idea of testing against a specially named argument.
>Why couldn't you just have a different decorator, such as
>"overload_chained" which triggers this behavior?
The PEP lists *five* built-in decorators, all of which support this behavior::
@overload, @when, @before, @after, @around
And in addition, it demonstrates how to create *new* method combination
decorators, that *also* support this behavior (e.g. '@discount').
All in all, there are an unbounded number of possible decorators that would
require chained and non-chained variations.
The other alternative would be to have a "magic" function like
"get_next_method()" that you could call, but the setup for such an animal
is more complex and would likely involve either sys._getframe() or some
kind of special thread variable(s). Performance would also be reduced for
*all* generic function invocations, because the setup would have to occur
whether or not chaining was happening. The argument list technique allows
the overhead to happen only once, and only when it's needed.
One new possibility, however... suppose we did it like this:
from overloading import next_method
@overload
def foo(blah:next_method, ...):
That is, if we used an argument *annotation* to designate the argument that
would receive the next method? For efficiency's sake, it would still need
to be the first argument, but at least the special name would go away, and
you could call it whatever you like.
More information about the Python-3000
mailing list