On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote: >> Message: 1 >> Date: Wed, 31 Mar 2004 18:10:23 +0200 >> From: Simon Percivall <s.percivall at chello.se> >> Subject: Re: [Python-Dev] Re: PEP 318: Decorators last before colon > > I've been following this discussion closely and I would like to voice > my > opinion. > > Please don't add any decorator syntax to Python, at least not yet. All > of the proposals I have seen so far are, to be blunt, and in my opinion > of course, ugly and are getting uglier as the discussion ensues. > > I see nothing wrong, at least for the present, with the status quo > decorators that follow a function or class definition. They are > explicit, functionally equivalent, use the existing and completely > understandable syntax, and are so rarely used by only the *most* > experienced and advanced programmers that violating the beauty of the > language is unjustified. I've been pretty quiet about this lately because the discussions have gone into space, largely by people who don't even have a need or desire for decorators, but uninformed comments like this just irk me. Decorators *are not rare* and are *used by regular programmers* in some problem domains. Yes, it takes an advanced programmer to write such a framework, but that doesn't mean that the syntax is useless to non-advanced programmers. It's particularly applicable to applications using PyObjC or ctypes where the function simply will not work unless it's decorated with the correct type signature. It can also potentially make pure python frameworks such as Twisted, ZopeX3, or PEAK easier to use, by moving boilerplate wrapping stuff into decorators. Decorators solve a *huge* problem with the current syntax: def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(takes, some, args, here): pass someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ = objc.selector(someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonge r_, signature='some type signature') versus (Guido's latest suggested syntax, which I approve of, even though I prefer the after-args-brackets): [objc.selector(signature='some type signature')] def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(self, some, args, here): pass Please understand that just because you haven't need them yet doesn't make them worthless, ugly, etc. It has nothing to do with being an experienced or advanced programmer, some problem domains simply REQUIRE decorated functions in order to work at all. If decorators do not make Python 2.4, that is another major release cycle that extensions such as PyObjC and ctypes will be hampered by lack of syntax... to the point where I'd be inclined to just fork Python (or Stackless, more likely) in order to get the syntax. -bob
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4