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

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

More information about the Python-3000 mailing list