[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

At 02:22 PM 5/1/2007 -0400, Jason Orendorff wrote:
>On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 09:13 AM 5/1/2007 -0700, Talin wrote:
>> >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
>
>Actually @before and @after don't support __proceeds__,
>according to the first draft anyway.

True; anything that derives from MethodList isn't going to need it, so that 
means that @discount won't use it, either.

Still, that's three decorators left: @overload, @when, and @around, plus 
any custom decorators based on Method in place of MethodList.  (@when and 
@around are implemented as the 'make_decorator' of Method and Around, 
respectively.)


>I think I would prefer to *always* pass the next method
>to @around methods, which always need it, and *never*
>pass it to any of the others.  What use case am I missing?

Calling the next method in a generic function is equivalent to calling 
super() in a normal method.  Anytime you want to add more specific behavior 
for a type, while reusing the more general behavior, you're going to need 
it.  Therefore, "primary" methods are always potential users of it.

Syntactically speaking, I would certainly agree that the ideal solution is 
something that looks like a super() call; it's just that supporting that 
requires *more* of the sort of hackery that Guido wants *less* of 
here.  Signature inspection isn't as much of a black art as magical 
functions that need to know how the current function was invoked.

The other possibility would be to clone the functions using copied 
func_globals (__globals__?) so that 'next_method' in those namespaces would 
point to the right next method.  But then, if the function *writes* any 
globals, it'll be updating the wrong namespace.  Do you have any other ideas?