[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

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 "overloadchained" 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