[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

      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