At 02:22 PM 5/1/2007 -0400, Jason Orendorff wrote: >On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> 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? _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
