Author infinity0
Recipients Guido.van.Rossum, benjamin.peterson, dirn, eric.araujo, eric.smith, eric.snow, gvanrossum, infinity0, james, ncoghlan, peyton
Date 2015-03-31.12:58:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427806680.34.0.0019116773529.issue19660@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-03-31 12:58:00infinity0setrecipients: + infinity0, gvanrossum, ncoghlan, eric.smith, benjamin.peterson, eric.araujo, eric.snow, dirn, Guido.van.Rossum, james, peyton
2015-03-31 12:58:00infinity0setmessageid: <1427806680.34.0.0019116773529.issue19660@psf.upfronthosting.co.za>
2015-03-31 12:58:00infinity0linkissue19660 messages
2015-03-31 12:58:00infinity0create