Alternative decorator syntax decision
gerrit.muller at embeddedsystems.nl
Fri Aug 20 10:53:05 CEST 2004
Paul Rubin wrote:
> "Paul McGuire" <ptmcg at austin.rr._bogus_.com> writes:
>>I would propose a multivote survey: each poster gets 3 votes among the
>>lettered choices on the Wiki page above. You can use all 3 for a single
>>option, or split them across 2 or 3 options if you are open to more than
> 1. My favorite variant was not in the list.
> 2. Any of the choices will have far reaching consequences that aren't
> yet thought out very well. There is not yet enough experience
> programming with the existing mechanisms (classmethods etc.) to
> be sure what's really worthwhile.
> 3. There's not all that much discussion on the wiki of how other
> languages do this stuff.
> 4. There's nowhere near consensus that any of the choices presented so
> far are not plain horrible.
> My conclusion: Python 2.4 should not have new decorator syntax. Stay
> with the existing stuff, for now.
> Discussion and exploration should continue and the question should be
> revisited for 2.5. For 2.4, extend the current kludgy (decorators
> separated from the function) mechanism if needed to provide necessary
> functionality, but deprecate any new such feature as soon as it's
> introduced, with the explanation that it's exploratory.
Hear, Hear! I just replied in a similar way, before reading your response.
Gaudi systems architecting:
More information about the Python-list