Hi there, Today I hit a limitation of decorator syntax, and I was wondering if maybe this limitation could be removed, or if they could allow more. The grammar for decorators is[1]: decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE But `dotted_name` doesn't allow to write things like the comment put in the snippet attached, or this smaller snippet: @M(b).decorator() def wrapped_func(): pass Although it looks possible to me to add this syntax, I was wondering if it had been discussed previously, and if I could see that discussion. All discussions I found were a lot older, arround the time decorators were designed and the syntax was being choosen. I also read PEP306 and PEP318. This is not a blocking issue since you can do with a temporary variable, but I was wondering what were your thoughts on this. Thank you very much, [1]: http://docs.python.org/3.3/reference/grammar.html ===== Snippet ========== class foo_decorator: def __init__(self): pass def __call__(self, func): return func class Foo: def test(self): return foo_decorator() class Bar: def __init__(self): self._foo = Foo() def M(val): return val._foo b = Bar() # SyntaxError: @M(b).test() m = M(b) @m.test() def func(): print('Hello World!') func() ======================== -- Franck Michea - EPITA/LSE/GISTRE 2014
I've found that a lot of the decorator syntax limitations can be worked
around with an identity decorator:
i = lambda x: x
@i(M(b).decorator())
def wrapped_func():
pass
kind of ugly, but it works
On Thu, Feb 20, 2014 at 1:31 PM, Franck Michea
Hi there,
Today I hit a limitation of decorator syntax, and I was wondering if maybe this limitation could be removed, or if they could allow more.
The grammar for decorators is[1]:
decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
But `dotted_name` doesn't allow to write things like the comment put in the snippet attached, or this smaller snippet:
@M(b).decorator() def wrapped_func(): pass
Although it looks possible to me to add this syntax, I was wondering if it had been discussed previously, and if I could see that discussion.
All discussions I found were a lot older, arround the time decorators were designed and the syntax was being choosen. I also read PEP306 and PEP318.
This is not a blocking issue since you can do with a temporary variable, but I was wondering what were your thoughts on this.
Thank you very much,
[1]: http://docs.python.org/3.3/reference/grammar.html
===== Snippet ========== class foo_decorator: def __init__(self): pass
def __call__(self, func): return func
class Foo: def test(self): return foo_decorator()
class Bar: def __init__(self): self._foo = Foo()
def M(val): return val._foo
b = Bar()
# SyntaxError: @M(b).test() m = M(b) @m.test() def func(): print('Hello World!')
func() ========================
-- Franck Michea - EPITA/LSE/GISTRE 2014 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Feb 20, 2014 at 10:31:45PM +0100, Franck Michea wrote:
Hi there,
Today I hit a limitation of decorator syntax, and I was wondering if maybe this limitation could be removed, or if they could allow more.
I recall that the limitation on decorator syntax was deliberate, because people weren't sure how confusing it would be to allow arbitrary expressions. I think that it might be time to extend the allowed syntax a bit. I think it is perfectly reasonable to allow:
@M(b).decorator() def wrapped_func(): pass
as syntax. -- Steven
20.02.2014 22:31, Franck Michea wrote:
Today I hit a limitation of decorator syntax, and I was wondering if maybe this limitation could be removed, or if they could allow more.
The grammar for decorators is[1]:
decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
But `dotted_name` doesn't allow to write things like the comment put in the snippet attached, or this smaller snippet:
@M(b).decorator() def wrapped_func(): pass
Although it looks possible to me to add this syntax, I was wondering if it had been discussed previously, and if I could see that discussion.
All discussions I found were a lot older, arround the time decorators were designed and the syntax was being choosen. I also read PEP306 and PEP318.
This is not a blocking issue since you can do with a temporary variable, but I was wondering what were your thoughts on this.
AFAIR, there was some discussion a year or a few years ago -- unfortunately I don't remember the details (of course it must be in archives of python-ideas (or maybe python-dev?)). As far as I remember, generally, the belief that this restriction is necessary seemed not to be very strong. Cheers. *j
On Thu, Feb 20, 2014 at 01:37:51PM -0800, Haoyi Li
I've found that a lot of the decorator syntax limitations can be worked around with an identity decorator:
i = lambda x: x @i(M(b).decorator()) def wrapped_func(): pass
Wow, what a trick! Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 21 February 2014 07:55, Jan Kaliszewski
As far as I remember, generally, the belief that this restriction is necessary seemed not to be very strong.
Yup, but the gains aren't that great, either - it's never irritated anyone enough for them to write up the necessary PEP and implement the Grammar change :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Feb 20, 2014 at 10:58 PM, Nick Coghlan
On 21 February 2014 07:55, Jan Kaliszewski
wrote: As far as I remember, generally, the belief that this restriction is necessary seemed not to be very strong.
Yup, but the gains aren't that great, either - it's never irritated anyone enough for them to write up the necessary PEP and implement the Grammar change :)
Cheers, Nick.
Well, I started to work on a public API design and was hoping I could use this pattern, but I had another idea since then that would work without syntax modification. Not promising anything, but I may look into this within the next few months (~9) if it bothers me enough :) Haoyi's trick is awesome, but I don't think it's a good idea for something public :/ Though I'll keep that in mind if I ever need that in my code :) Thank you for your answers guys! -- Franck Michea - EPITA/GISTRE/LSE 2014
participants (6)
-
Franck Michea
-
Haoyi Li
-
Jan Kaliszewski
-
Nick Coghlan
-
Oleg Broytman
-
Steven D'Aprano