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

[Phillip J. Eby]

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.