This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
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)

I don't know the rational behind disallowing bar().foo(), but it is the use-case I have in mind - something like:

def f(x):

or even

def f(x):

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:00infinity0setrecipients: + infinity0, gvanrossum, ncoghlan, eric.smith, benjamin.peterson, eric.araujo, eric.snow, dirn, Guido.van.Rossum, james, peyton
2015-03-31 12:58:00infinity0setmessageid: <>
2015-03-31 12:58:00infinity0linkissue19660 messages
2015-03-31 12:58:00infinity0create