Hi All, This is my first post to python-dev so I will briefly introduce myself: My name is Rob Cliffe and I am a commercial programmer living in London, UK. I have some 30 years of programming experience but have only been using Python for a couple of years. First I want to say what a fantastic language Python is. It is THE best language for development in my opinion, and a joy to use. My specific issue: I eventually got my head round decorator syntax and realised that what came after the '@' was (basically) a function that took a function as argument and returned a function as result. However it seems to me unPythonesque (i.e. an exception to Python's normal consistency) that the syntax of what follows the '@' should be restricted to either a single (function) identifier or a single (function) identifier with an argument list. The example I tried, which seems not an unreasonable sort of thing to do, was along the lines of: def deco1(func): <deco1-suite> def deco2(func): <deco2-suite> DecoList = [deco1, deco2] @DecoList[0] # NO - CAUSES SYNTAX ERROR def foo(): pass I am sure other guys have their own examples. I am of course not the first person to raise this issue, and I see that Guido has a "gut feeling" against allowing a general expression after the '@'. BUT - a general expression can be "smuggled in" very easily as a function argument: def Identity(x): return x @Identity(DecoList[0]) # THIS WORKS def foo(): pass 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? Best wishes Rob Cliffe
Crossposting to Python-ideas, I asked for the same change to the grammar a couple months back on python-ideas. See http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 I'm all for it, but you'll have to convince Guido that this won't result in confusing to read code. My own examples, unfortunately did not advance your cause, as Guido explained, "My brain hurts trying to understand all this. I don't think this bodes well as a use case for a proposed feature." :-D The trouble is that I was using lambdas upon lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come up with some simple, clear use cases though, and I think he might still be persuadable to make a simple change to the grammar. — Carl Johnson Rob Cliffe <rob.cliffe@btinternet.com> wrote:
I actually encountered this for the first time yesterday and didn't realise that the decorator syntax was limited in this way (I was mentally preparing a blog entry when these emails arrived). What I needed to do was turn a Python function into a .NET event handler in IronPython. The simple case is this: from System import EventHandler @EventHandler def on_event(sender, event): # do stuff... This works fine of course, but then I needed to use the 'typed' form which is like this: @EventHandler[HtmlEventArgs] def on_event(sender, event): # do stuff... I didn't realise this was invalid syntax - nor the neat trick with the identity function to bypass the limitation. Michael 2009/9/2 Carl Johnson <cmjohnson.mailinglist@gmail.com>
People, please note that the discussion has shifted to python-ideas and further comments should happen over there. Carl did the right thing to shift it there, although cross-posting once the conversation redirection has occurred is not needed. hoping-google-wave-will-have-a-permanent-redirector-for-conversations-ly yrs, Brett On Wed, Sep 2, 2009 at 03:34, Carl Johnson<cmjohnson.mailinglist@gmail.com> wrote:
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
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. :) Here's some of the more relevant messages from the thread back when the @decorator feature was first introduced: http://mail.python.org/pipermail/python-dev/2004-August/046654.html http://mail.python.org/pipermail/python-dev/2004-August/046659.html http://mail.python.org/pipermail/python-dev/2004-August/046675.html http://mail.python.org/pipermail/python-dev/2004-August/046711.html http://mail.python.org/pipermail/python-dev/2004-August/046741.html http://mail.python.org/pipermail/python-dev/2004-August/046753.html http://mail.python.org/pipermail/python-dev/2004-August/046818.html James
On Wed, Sep 2, 2009 at 10:35 AM, James Y Knight<foom@fuhm.net> wrote:
I think Guido may have a point about not allowing any arbitrary expression. But I do think that if it allows calls, it should also at least support the itemgetter syntax, for which there seems to be a demonstrable use case. But that's just adding on another special case, so it might be simpler to allow arbitrary expressions.
Erik Bray wrote:
It's not the same issue, of course, but note that str.format's object specification "language" supports item and attribute access. And that's the extent of what it allows. If you wanted to do this for decorators, I'm not sure how easy it would be to restrict the expression inside the brackets, or if you'd even want to. str.format has all of this baked-in, it doesn't use any sort of grammar. Eric
Crossposting to Python-ideas, I asked for the same change to the grammar a couple months back on python-ideas. See http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 I'm all for it, but you'll have to convince Guido that this won't result in confusing to read code. My own examples, unfortunately did not advance your cause, as Guido explained, "My brain hurts trying to understand all this. I don't think this bodes well as a use case for a proposed feature." :-D The trouble is that I was using lambdas upon lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come up with some simple, clear use cases though, and I think he might still be persuadable to make a simple change to the grammar. — Carl Johnson Rob Cliffe <rob.cliffe@btinternet.com> wrote:
I actually encountered this for the first time yesterday and didn't realise that the decorator syntax was limited in this way (I was mentally preparing a blog entry when these emails arrived). What I needed to do was turn a Python function into a .NET event handler in IronPython. The simple case is this: from System import EventHandler @EventHandler def on_event(sender, event): # do stuff... This works fine of course, but then I needed to use the 'typed' form which is like this: @EventHandler[HtmlEventArgs] def on_event(sender, event): # do stuff... I didn't realise this was invalid syntax - nor the neat trick with the identity function to bypass the limitation. Michael 2009/9/2 Carl Johnson <cmjohnson.mailinglist@gmail.com>
People, please note that the discussion has shifted to python-ideas and further comments should happen over there. Carl did the right thing to shift it there, although cross-posting once the conversation redirection has occurred is not needed. hoping-google-wave-will-have-a-permanent-redirector-for-conversations-ly yrs, Brett On Wed, Sep 2, 2009 at 03:34, Carl Johnson<cmjohnson.mailinglist@gmail.com> wrote:
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
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. :) Here's some of the more relevant messages from the thread back when the @decorator feature was first introduced: http://mail.python.org/pipermail/python-dev/2004-August/046654.html http://mail.python.org/pipermail/python-dev/2004-August/046659.html http://mail.python.org/pipermail/python-dev/2004-August/046675.html http://mail.python.org/pipermail/python-dev/2004-August/046711.html http://mail.python.org/pipermail/python-dev/2004-August/046741.html http://mail.python.org/pipermail/python-dev/2004-August/046753.html http://mail.python.org/pipermail/python-dev/2004-August/046818.html James
On Wed, Sep 2, 2009 at 10:35 AM, James Y Knight<foom@fuhm.net> wrote:
I think Guido may have a point about not allowing any arbitrary expression. But I do think that if it allows calls, it should also at least support the itemgetter syntax, for which there seems to be a demonstrable use case. But that's just adding on another special case, so it might be simpler to allow arbitrary expressions.
Erik Bray wrote:
It's not the same issue, of course, but note that str.format's object specification "language" supports item and attribute access. And that's the extent of what it allows. If you wanted to do this for decorators, I'm not sure how easy it would be to restrict the expression inside the brackets, or if you'd even want to. str.format has all of this baked-in, it doesn't use any sort of grammar. Eric
participants (9)
-
Brett Cannon -
Carl Johnson -
Eric Smith -
Erik Bray -
James Y Knight -
Michael Foord -
MRAB -
Rob Cliffe -
Xavier Morel