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

Phillip J. Eby pje at telecommunity.com
Wed May 2 04:47:07 CEST 2007

At 07:21 PM 5/1/2007 -0700, Talin wrote:

Well, I suppose you could make "chained" a modifier of the decorator, so for example @operator.chained, @discount.chained, and so on. In other words, the decorator can be called directly, or the attribute 'chained' also produces a callable that causes the modified behavior.

Well, that certainly seems like enough of an option to list as an alternative in the PEP, but I personally think it increases implementation complexity, compared to the way things work now. One reason for that is that right now the decorators don't actually do much of anything, as per this excerpt from peak.rules.core::

     def decorate(f, pred=()):
         rules = rules_for(f)
         def callback(frame, name, func, old_locals):
             rule = parse_rule(
                 rules, func, pred, maker, frame.f_locals, frame.f_globals
             )
             rules.add(rule)
             if old_locals.get(name) in (f, rules):
                 return f    # prevent overwriting if name is the same
             return func
         return decorate_assignment(callback)

The above is the function used for all of the decorators proposed in the PEP, except for @overload. The only bit that differs between them is the maker, which is a classmethod of the corresponding Method class (e.g. Method, Before, Around, etc.). The maker is used to create action instances, which are then combined into chains using combine_actions(). The signature stuff for proceed (which is actually called 'next_method' in peak.rules) is done inside the maker and the action instance itself, not in the decorator.

So, it would require a fair amount of refactoring and additional complexity to do it the way you suggest. It's intriguing, but I'm not sure it's a big win compared to e.g. "def foo(next:next_method, ...)". I could see allowing the next_method to be in a different position, since the partial() can still be precomputed, and bound methods could still be used in the case where it was in the first position.

Moreover, this would support an arbitrary number of modifiers on the decorator, such as @overload.chained.strict(True).whatever.

Actually, I don't think Python's grammar allows you to do that. IIRC, decorators have to be a dotted name followed by an optional (arglist). So the '.whatever' part wouldn't be legal.

More information about the Python-3000 mailing list