[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
Phillip J. Eby
pje at telecommunity.com
Tue May 1 20:48:54 CEST 2007
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
>> @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,
>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?
More information about the Python-3000