Message239697
Yes, please get rid of this restriction. It's trivial to get around - you don't even need to define your own "pass-through", one already exists in the standard library:
>>> @(lambda: [lambda x: x][0])()
File "<stdin>", line 1
@(lambda: [lambda x: x][0])()
^
SyntaxError: invalid syntax
>>> from functools import partial as _
>>> @_( (lambda: [lambda x: x][0])() )
... def f(x): return x*x
...
>>> f(3)
9
I don't know the rational behind disallowing bar().foo(), but it is the use-case I have in mind - something like:
@MainDecoratorFactory(params).tweakedDecorator(tweak_params)
def f(x):
pass
or even
@MainDecoratorFactory(params).\
tweakedDecorator(tweak_params)
def f(x):
pass
It should be no more controversial than chaining decorators.
The alternative with the current restrictions would be tweakedDecorator(MainDecorator(params), tweak_params) which is more ugly and visually separates the "tweak" concepts.
It's not appropriate to merge MainDecoratorFactory and the tweaks together: there are several MainDecoratorFactories taking care of one main concern; they don't care about the tweaks. And vice versa; the tweaks shouldn't care about the main decorators. |
|
Date |
User |
Action |
Args |
2015-03-31 12:58:00 | infinity0 | set | recipients:
+ infinity0, gvanrossum, ncoghlan, eric.smith, benjamin.peterson, eric.araujo, eric.snow, dirn, Guido.van.Rossum, james, peyton |
2015-03-31 12:58:00 | infinity0 | set | messageid: <1427806680.34.0.0019116773529.issue19660@psf.upfronthosting.co.za> |
2015-03-31 12:58:00 | infinity0 | link | issue19660 messages |
2015-03-31 12:58:00 | infinity0 | create | |
|