[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
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
if old_locals.get(name) in (f, rules):
return f # prevent overwriting if name is the same
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