Re: [Python-ideas] Decorator syntax
MRAB schrieb:
James Y Knight wrote:
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
So - the syntax restriction seems not only inconsistent, but pointless; it doesn't forbid anything, but merely means we have to do it in a slightly convoluted (unPythonesque) way. So please, Guido, will you reconsider?
Indeed, it's a silly inconsistent restriction. When it was first added I too suggested that any expression be allowed after the @, rather than having a uniquely special restricted syntax. I argued from consistency of grammar standpoint. But Guido was not persuaded. Good luck to you. :)
[snip] I can see no syntactic reason to restrict what can appear after the @. If someone chooses to abuse it then that's unPythonic, but not illegal.
I do see a reason. I have no problems with @foo.bar @foo.bar[baz] @foo.bar(baz) But this is ugly to me: @a + b def foo(): pass As is this: @a or (c and d) def foo(): pass Having the decorator expression "opened" by @ but not "closed" feels bad. However, this looks better to me: @(a + b) @(a or (c and d)) So, in terms of Grammar/Grammar, what about decorator: '@' atom trailer* NEWLINE [x-post to ideas list] Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg Brandl wrote:
MRAB schrieb:
James Y Knight wrote:
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
So - the syntax restriction seems not only inconsistent, but pointless; it doesn't forbid anything, but merely means we have to do it in a slightly convoluted (unPythonesque) way. So please, Guido, will you reconsider? Indeed, it's a silly inconsistent restriction. When it was first added I too suggested that any expression be allowed after the @, rather than having a uniquely special restricted syntax. I argued from consistency of grammar standpoint. But Guido was not persuaded. Good luck to you. :)
[snip] I can see no syntactic reason to restrict what can appear after the @. If someone chooses to abuse it then that's unPythonic, but not illegal.
I do see a reason. I have no problems with
@foo.bar @foo.bar[baz] @foo.bar(baz)
But this is ugly to me:
@a + b def foo(): pass
Ugly, yes.
As is this:
@a or (c and d) def foo(): pass
Agreed.
Having the decorator expression "opened" by @ but not "closed" feels bad.
But: @foo isn't "closed" either.
However, this looks better to me:
@(a + b) @(a or (c and d))
Conditions in 'if' and 'while' statements don't need parentheses, so why do decorators?
So, in terms of Grammar/Grammar, what about
decorator: '@' atom trailer* NEWLINE
I say "keep it clean", ie no parentheses except where operator priority or clarity require them. IMHO, if a user writes something that's ugly then call it unPythonic; consenting adults and all that. :-)
MRAB wrote:
However, this looks better to me:
@(a + b) @(a or (c and d))
Conditions in 'if' and 'while' statements don't need parentheses, so why do decorators?
Those are already closed by the colon so requiring parentheses would be redundant: if a + b: while a + b: The minimalist tweak would be to follow Guido's preference and just accept subscripting in addition to calls.
So, in terms of Grammar/Grammar, what about
decorator: '@' atom trailer* NEWLINE
I say "keep it clean", ie no parentheses except where operator priority or clarity require them.
I actually agree with Georg that this is a case where clarity favours enforced parentheses for expressions that are otherwise non-atomic. Things like variable references, function calls and subscripting are already atomic so the parentheses would be optional in those cases. However, as long as Guido remains -0 extension to arbitrary expressions isn't going to happen, parentheses or no parentheses. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
MRAB wrote:
However, this looks better to me:
@(a + b) @(a or (c and d))
Conditions in 'if' and 'while' statements don't need parentheses, so why do decorators?
Those are already closed by the colon so requiring parentheses would be redundant:
if a + b: while a + b:
I forgot about 'return': return a + b
The minimalist tweak would be to follow Guido's preference and just accept subscripting in addition to calls.
So, in terms of Grammar/Grammar, what about
decorator: '@' atom trailer* NEWLINE
I say "keep it clean", ie no parentheses except where operator priority or clarity require them.
I actually agree with Georg that this is a case where clarity favours enforced parentheses for expressions that are otherwise non-atomic. Things like variable references, function calls and subscripting are already atomic so the parentheses would be optional in those cases.
However, as long as Guido remains -0 extension to arbitrary expressions isn't going to happen, parentheses or no parentheses.
MRAB schrieb:
I do see a reason. I have no problems with
@foo.bar @foo.bar[baz] @foo.bar(baz)
But this is ugly to me:
@a + b def foo(): pass
Ugly, yes.
As is this:
@a or (c and d) def foo(): pass
Agreed.
Good :)
Having the decorator expression "opened" by @ but not "closed" feels bad.
But:
@foo
isn't "closed" either.
Hmm, the above is probably a bad expression of my "feeling" :) but I think you know what I mean. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
I would say here are two more things to consider:
(1) How to colorize expression @a or b and c? My IDE colorizes only @a
as decorator
(2) How to search for all functions that have been applied decorator
`b` (*not* either `a` or `b`)?
(bonus) How to test expression of the above form? By definition, you
will have only *one* function decorated like that. To test it, you
should define it as a separate function anyway.
ilya.
On Thu, Sep 3, 2009 at 3:27 PM, Georg Brandl
MRAB schrieb:
I do see a reason. I have no problems with
@foo.bar @foo.bar[baz] @foo.bar(baz)
But this is ugly to me:
@a + b def foo(): pass
Ugly, yes.
As is this:
@a or (c and d) def foo(): pass
Agreed.
Good :)
Having the decorator expression "opened" by @ but not "closed" feels bad.
But:
@foo
isn't "closed" either.
Hmm, the above is probably a bad expression of my "feeling" :) but I think you know what I mean.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Georg Brandl wrote:
@foo.bar @foo.bar[baz]
To me, this is easier to read (conceptualize), because it simply selects a metafunction, than the current
@foo.bar(baz)
, which calls a metafunction that creates and returns a metafunction. So I hope it gets added if not too difficult. I have some sympathy for Guido's position that anything more complicated should be split into two lines. That should be mentioned in the docs whether or not @f[i] is added. tjr
participants (5)
-
Georg Brandl -
ilya -
MRAB -
Nick Coghlan -
Terry Reedy