-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decorator syntax: allow testlist instead of just dotted_name #63859
Comments
Decorator syntax currently allows only a dotted_name after the @. As far as I can tell, this was a gut-feeling decision made by Guido. [1] I spoke with Nick Coghlan at PyTexas about this, and he suggested that if someone did the work, there might be interest in revisiting this restriction. The attached patch allows any testlist to follow the @. The following are now valid: @(lambda x:x) @(spam if p else eggs)
def f():
pass
@spam().ham().eggs()
def f():
pass [1] http://mail.python.org/pipermail/python-dev/2004-August/046711.html |
Thanks for this! Tests should exercise the now-valid syntaxes, which also need documentation. |
On second thought, as this patch allows one form that Guido doesn’t want (bar().foo()), maybe there should be a discussion on python-ideas. |
Nice! As a syntax change (albeit a minor one), I believe this will require a PEP for Python 3.5. I know Guido indicated he was OK with relaxing the current restrictions, but I don't remember exactly where he said it, or how far he was willing to relax them. |
I don't feel very strongly, but I do think that most of the things the new syntax allows are not improvements -- they make the decorator harder to read. It was intentional to force you to compute a variable before you can use it as a decorator, e.g. spamify = (spam if p else eggs)
@spamify
def f():
pass |
I agree. |
I see this as removing a restriction and a special-case from the In terms of whether the new forms are improvements, my preference is to I would argue that this change does not force any additional complexity I would also argue that there are certainly cases where, in the midst of This is likely true for: class Foo:
def bar(self, func):
return func
@staticmethod
def baz(func):
return func
@staticmethod
def quux():
def dec(func):
return func
return dec
# invalid
@Foo().bar
def f(): pass
# valid
@Foo.baz
def f(): pass
# valid
@Foo.quux()
def f(): pass For completeness' sake, I have attached a patch with an additional unit Should we proceed with writing a PEP for Python 3.5? |
Yes, a PEP for 3.5 on this will be valuable, whether it's accepted or not If I recall the past python-ideas threads correctly, the main objections to
def deco(x): return x
Now that the precedent of keeping decorator expressions simple has been |
I think the complexity delta in the grammar is exactly 0. |
While I think that the dotted_name restriction should be relaxed and it should instead be a style guide issue, I have to agree with Benjamin here: the difference in grammar complexity is zero and shouldn't drive the decision. |
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).\ 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. |
Nobody has posted a real use case. All the examples are toys. What are the |
TL;DR - Use case is dynamic decorators. Not all of the syntax would make sense, see below. The main benefit of this feature would be for dynamic decorators (as was evidenced from others in this issue). In a project I contribute to, we use dynamic decorators to set a function as being a command, and we use the object (a wrapper around the function) directly, so we need a bit more boilerplate around the place. Ultimately, we would definitely use such a feature (just the '@spam().eggs()' part; we'd have no use for the other ones) , but we probably won't notice its absence either; we've worked around it for years, after all. As far as readability goes, I think allowing only the '@spam().eggs()' version would actually improve readability quite a bit, by reducing the need to separate the decorator assignment in two (or more) parts. I can see the desire to have a '@spam[eggs]' kind of syntax though, again for the dynamic decorators case. I see no reason to allow creating lambdas or conditional expressions inside decorators expressions. If anything, that'll encourage anti-patterns, whereas e.g. '@spam(value=eggs)' would be more readable, and would let the decorator decide what it wants to do with the value. And if your decorator can be expressed as a lambda, why don't you put that in/below the function? Surely it's less work than writing the lambda everytime ;) |
Could you link to an example decorator definition and its call site(s) |
Sure, here goes; this is an IRC game bot which I contribute to. Apologies for the long links, it's the only way to make sure this consistently points to the same place regardless of future commits. The 'cmd' decorator we use is defined at https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/decorators.py#L67 - we use its __call__ method to add the function to it; see next link. How it's used: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L9113 - ideally, a syntax such as the following would be nice for these definitions: @cmd("myrole", <keyword arguments here>).set Historically (we used an arcane closure-based version that no one understood), we could call that function after directly, like any normal function. Now, though, we have to call it like this: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L764 I'd like to state again that, while we'd use this new syntax, we've already worked around this lack of syntax. Whatever comes out of this, we won't be negatively affected, but decorators are meant to bring whatever alters the function right where it starts, so having syntax that eases that would make sense (to me, anyway). |
OK, so if you wanted to be able to call myrole(...) instead of |
We want to be able to access the instance attributes (as is done e.g. here: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L9761 ). I realize we can set the attributes directly on the functions, but we've decided to not do that (it's a style thing, really). Although I guess a class method which then returns our desired method could work out for us. While I still think that this kind of syntax might be useful for dynamic decorators (I know I'd use that when playing with decorators), I'm afraid I'm out of concrete examples to send your way. |
OK, maybe someone else wants to provide a real-world example. |
Real world example where this actually came up: |
There is again some discussion about this at https://discuss.python.org/t/why-are-some-expressions-syntax-errors/420 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: