Plea for simpler decorator syntax, in addition to pie-shaped syntax
IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax: def classmethod foo(cls, ...): ... This simplified syntax only allows names to specify decorators. It could allow multiple names, although I'm not sure it should, I find this *far* more readable and obvious than any of the other syntaxs I've seen propsed. Those applications that *need* decorator arguments could use the more complex pie-shaped notation. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wednesday 04 August 2004 10:52 am, Jim Fulton wrote:
IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax:
def classmethod foo(cls, ...): ...
This was rejected a long time ago because it complicated life for editor colorizing support and many similar tools. It especially complicates the creation of ad-hoc tools, and breaks ones that are already working. While pie-notation isn't my favorite, it's reasonable enough. The example @classmethod def makeAnother(cls): return cls("magic", 42) seems readable enough to me. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
def classmethod foo(cls, ...): ...
This was rejected a long time ago because it complicated life for editor colorizing support
Oh, Fred, please! "Complicated life"? (and, "Editor colorizing support"?!) Much as I love python-mode, it hardly seems a good reason to add a whole new syntactic branch to Python, particularly when editors are really good at identifying a small set of distinguished words in distinguished positions. By the way, if we're going down the road of compile-time markup, how about a real macro language :-? Bill
Fred> This was rejected a long time ago because it complicated life for Fred> editor colorizing support Bill> Much as I love python-mode, it hardly seems a good reason to add a Bill> whole new syntactic branch to Python, .. Though X/Emacs is popular within the Unix community, it's hardly the only editor that attempts to colorize Python code: http://www.python.org/cgi-bin/moinmoin/PythonEditors In fact, given the increased use of Python on Windows these days I'm skeptical it's the most widely used editor for Python code. (Not breaking etags/ctags is also a nice-to-have.) Skip
In fact, given the increased use of Python on Windows these days I'm skeptical it's the most widely used editor for Python code.
Didn't mean to imply that it was, it's just what I use. By the way, I had firmly resolved to keep quiet about this decorators issue, but I lost my willpower there for a minute :0). Bill
Skip Montanaro:
Though X/Emacs is popular within the Unix community, it's hardly the only editor that attempts to colorize Python code:
http://www.python.org/cgi-bin/moinmoin/PythonEditors
In fact, given the increased use of Python on Windows these days I'm skeptical it's the most widely used editor for Python code.
Many of the other editors use the Scintilla editing component and rely on its built-in Python lexer. If no one else gets to it first, I'll update the lexer to recognize pie shaped decorators. Or whichever other syntax is accepted. Neil
Jim, you should've argued this months ago. Everything you bring up has already been debated endlessly, and I really don't feel like regurgitating the same answer again. Please stop. --Guido van Rossum (home page: http://www.python.org/~guido/)
IMO, the most common uses of decorators will be to define properties, and class and static methods.
I thought we had decided that properties weren't one of the things addressed by the decorator mechanism? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax:
def classmethod foo(cls, ...): ...
This simplified syntax only allows names to specify decorators. It could allow multiple names, although I'm not sure it should,
I find this *far* more readable and obvious than any of the other syntaxs I've seen propsed.
Agreed.
Those applications that *need* decorator arguments could use the more complex pie-shaped notation.
I wouldn't care to define a decorator function to introduce arguments, and force every decorator function to take a single argument. -- Gustavo Niemeyer http://niemeyer.net
In article <20040805174619.GB27820@burma.localdomain>, Gustavo Niemeyer <niemeyer@conectiva.com> wrote:
IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax:
def classmethod foo(cls, ...): ...
This simplified syntax only allows names to specify decorators. It could allow multiple names, although I'm not sure it should,
I find this *far* more readable and obvious than any of the other syntaxs I've seen propsed.
Agreed.
Disagreed. It works fine when the decorator is as short as "classmethod" and the function signature is as short as "foo(cls, ...)". It breaks down when those are long enough that the whole thing doesn't fit on a single line, which I'm expecting will happen a reasonably large fraction of the time. I like pie. -- David Eppstein Computer Science Dept., Univ. of California, Irvine http://www.ics.uci.edu/~eppstein/
[Gustavo Niemeyer]
IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax:
def classmethod foo(cls, ...): ...
I've seen this example several times today, and I have to say that every time I've seen it, my unstoppable gut reaction was "wait, why are they defining their own classmethod function here?!". I've had that problem since the first time this syntax vairant was suggested (loooooong ago), and it's not going away. Maybe it's 10+ years of "in Python, the name of the function comes after the 'def'" and I just can't adjust that to qualify "but is the *last* name after a 'def' preceding the first left paren following the 'def'"; or maybe it's because I've written God-only-knows how many tools that believe the same thing (the Emacs python-mode parser; the IDLE parser; any number of one-shot cheap-ass regexps). Whatever, I can't get used to it. So, sorry, but I like @classmethod def foo(cls, ...): unboundedly better than that. For that matter, I like it at least as well as any alternative to date, and better than most. I actively hate putting stuff between 'the def' and the function name. Then again, I'm old <wink>.
participants (10)
-
Bill Janssen -
David Eppstein -
Fred L. Drake, Jr. -
Greg Ewing -
Guido van Rossum -
Gustavo Niemeyer -
Jim Fulton -
Neil Hodgson -
Skip Montanaro -
Tim Peters