[issue37196] Allowing arbitrary expressions in the @expression syntax

2020-02-20 Thread Brandt Bucher
Change by Brandt Bucher : -- nosy: +brandtbucher resolution: -> duplicate status: open -> closed superseder: -> PEP 614: Relaxing Grammar Restrictions On Decorators ___ Python tracker __

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Guido van Rossum
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Géry
Géry added the comment: @Guido van Rossum > What you want to write is as unreadable as it ever was. How is @g(f()()) more readable than @f()()? Yet the former is allowed. -- resolution: wont fix -> status: closed -> open ___ Python tracker

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Guido van Rossum
Guido van Rossum added the comment: What you want to write is as unreadable as it ever was. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker _

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Géry
Géry added the comment: @Christian Heimes > The reasons are explained at: Yes I read that. But I am wondering if after 15 years Guido still has this "gut feeling". Because my gut feeling as a Python *user* who has discovered decorators and stumbled on this restriction was: "what?!". ---

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Christian Heimes
Christian Heimes added the comment: The syntax is deliberately limited. The reasons are explained at: https://www.python.org/dev/peps/pep-0318/#current-syntax https://mail.python.org/pipermail/python-dev/2004-August/046711.html -- nosy: +christian.heimes _

[issue37196] Allowing arbitrary expressions in the @expression syntax

2019-06-07 Thread Géry
New submission from Géry : Could we allow arbitrary expressions in the @expression syntax for applying decorators to functions/classes? The current grammar restriction to: decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE is very surprising and I don't understand the real motivation