Why aren't decorators just expressions?
The syntax for decorators in the grammar is quite specific: decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE Decorators can be either a dotted name, or a dotted name followed by arguments. This disallows: @mapping['async'] # looking something up in a mapping @func(1, 2, 3).async # getting the attribute of the /result/ of a function call Obviously these restrictions haven't been too burdensome, as I've labored under them for 13+ years and didn't even notice until just now. But it set me to wondering. If it were me, perpetually lazy sod that I am, I'd have written the grammar as decorator: '@' expr NEWLINE and been done with it. So why don't decorators allow arbitrary expressions? The PEP discusses the syntax for decorators, but that whole debate only concerned itself with where the decorator goes relative to "def", and what funny punctuation might it use. It never says "decorators shouldn't permit arbitrary expressions because--". Nor is there any info on wiki page with the extensive summary of alternative syntax proposals. Anybody remember? I'm not proposing that we allow arbitrary expressions as decorators... well, I'm not doing that /yet/ at least. But like I said, the syntax has been this way for 13 years and I don't recall anybody complaining. //arry /p.s. I experimentally tried modifying the grammar for descriptors to allow arbitrary expressions. The syntax was fine but it crashed in ast_for_decorator(). When I updated that to match, it worked fine! The diff is short and mainly consists of deleted code.
16.09.17 12:39, Larry Hastings пише:
So why don't decorators allow arbitrary expressions? The PEP discusses the syntax for decorators, but that whole debate only concerned itself with where the decorator goes relative to "def", and what funny punctuation might it use. It never says "decorators shouldn't permit arbitrary expressions because--". Nor is there any info on wiki page with the extensive summary of alternative syntax proposals.
Anybody remember?
https://mail.python.org/pipermail/python-dev/2004-August/046711.html
I'm not proposing that we allow arbitrary expressions as decorators... well, I'm not doing that /yet/ at least. But like I said, the syntax has been this way for 13 years and I don't recall anybody complaining.
This may be an argument for not changing the syntax. Actually I remember somebody raised this question a year or two ago, but don't remember details.
On 16 September 2017 at 21:22, Serhiy Storchaka <storchaka@gmail.com> wrote:
Actually I remember somebody raised this question a year or two ago, but don't remember details.
Aye, I remember that as well, but apparently the thread title for the discussion was sufficiently unrelated to the eventual topic that I can't find it with Google. Anyway, I think the outcome of that particular thread was something like: 1. The most reasonable-sounding enhancement request is the one to allow subscripts: "@deco_group[deco_id]" 2. If we're going to relax the restrictions at all, it probably makes sense to just allow arbitrary expressions 3. You can already use arbitrary expressions in practice by defining "def deco(x): return x", and then writing "@deco(whatever_expression_you_want)" 4. Nobody was motivated enough to actually implement the change and then ask Guido if he'd changed his mind on the topic since 2004 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hello, Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
16.09.17 12:39, Larry Hastings пише:
So why don't decorators allow arbitrary expressions? [...]
Actually I remember somebody raised this question a year or two ago,> but don't remember details.
The discussion I remember was https://bugs.python.org/issue19660 Guido said: «Nobody has posted a real use case. All the examples are toys. What are the real use cases that are blocked by this? Readability counts!» Cheers
I myself found out abotu this restriction once I clashesd into it- soit was one time the restriction bit me back. But I can't remember if that was for intended production code or for toying around either. Anyway, a simple "nop" function can allow for any arbitrary expression to be used as decorator, at expense of a little more line noise. And the restriction prevents the line noise to emerge as "cool" in some framework that mitg take inspiration in trends ongoing in other languages. nop = lambda f: f @nop(MyClass(things)[dimension1, dimension2[subdimension5]] + CombinableAutoMixinDecoFactory()) def my_func(): pass On 18 September 2017 at 18:33, Éric Araujo <merwok@netwok.org> wrote:
Hello,
Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
16.09.17 12:39, Larry Hastings пише:
So why don't decorators allow arbitrary expressions? [...]
Actually I remember somebody raised this question a year or two ago,> but don't remember details.
The discussion I remember was https://bugs.python.org/issue19660
Guido said: «Nobody has posted a real use case. All the examples are toys. What are the real use cases that are blocked by this? Readability counts!»
Cheers _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
On Sep 16, 2017, at 02:39, Larry Hastings <larry@hastings.org> wrote:
I'm not proposing that we allow arbitrary expressions as decorators... well, I'm not doing that yet at least. But like I said, the syntax has been this way for 13 years and I don't recall anybody complaining.
Indeed, I can’t remember a single time where I’ve needed that, let alone actually realized the restriction existed. But now that you mention it, I do remember discussions in favor of the more restricted syntax when the feature was originally being debated. I don’t remember the reasons though - it well could have been an abundance of caution over how far to take the new syntax (and understanding of course that it’s easier to relax than restrict). -Barry
I always realized the restriction was there, and once in a while mention it in teaching. But I've NEVER had an actual desire to use anything other that a simple decorator or a "decorator factory" (which I realize is a decorator in the grammar, but it's worth teaching how to parameterize custom ones, which is a factory). I've used barry_as_FLUFL more often, actually... Albeit always joking around for students, not in production covfefe. On Sep 16, 2017 9:46 AM, "Barry Warsaw" <barry@python.org> wrote: On Sep 16, 2017, at 02:39, Larry Hastings <larry@hastings.org> wrote:
I'm not proposing that we allow arbitrary expressions as decorators... well, I'm not doing that yet at least. But like I said, the syntax has been this way for 13 years and I don't recall anybody complaining.
Indeed, I can’t remember a single time where I’ve needed that, let alone actually realized the restriction existed. But now that you mention it, I do remember discussions in favor of the more restricted syntax when the feature was originally being debated. I don’t remember the reasons though - it well could have been an abundance of caution over how far to take the new syntax (and understanding of course that it’s easier to relax than restrict). -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mertz%40gnosis.cx
Indeed, I can’t remember a single time where I’ve needed that, let alone actually realized the restriction existed.
Likewise. I suspect the use of a function sort of just fell out from the pre-decorator usage. Things like staticmethod() <https://docs.python.org/2/library/functions.html#staticmethod> and classmethod() <https://docs.python.org/2/library/functions.html#classmethod> were used well before decorators were available. (According to the linked 2.7 doc references, both were introduced in 2.2, with decorator tweaks coming along in 2.4.) In fact, those two functions might have been the most significant driving force in the development of decorators, which, I believe, were always just thought if as nothing more than syntactic sugar for existing common use cases. Skip
It was and is all very intentional. I don't want to encourage line noise, which the at-sign already resembles. But namespacing and some form of parametrization (i.e. calls) are essential. So that's what we got. On Sep 16, 2017 11:30 AM, "Skip Montanaro" <skip.montanaro@gmail.com> wrote:
Indeed, I can’t remember a single time where I’ve needed that, let alone actually realized the restriction existed.
Likewise. I suspect the use of a function sort of just fell out from the pre-decorator usage. Things like staticmethod() <https://docs.python.org/2/library/functions.html#staticmethod> and classmethod() <https://docs.python.org/2/library/functions.html#classmethod> were used well before decorators were available. (According to the linked 2.7 doc references, both were introduced in 2.2, with decorator tweaks coming along in 2.4.) In fact, those two functions might have been the most significant driving force in the development of decorators, which, I believe, were always just thought if as nothing more than syntactic sugar for existing common use cases.
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org
participants (9)
-
Barry Warsaw -
David Mertz -
Guido van Rossum -
Joao S. O. Bueno -
Larry Hastings -
Nick Coghlan -
Serhiy Storchaka -
Skip Montanaro -
Éric Araujo