Alternative decorator syntax decision
pm_mon at yahoo.com
Wed Aug 25 00:59:56 CEST 2004
Jess Austin wrote:
> Paul Morrow <pm_mon at yahoo.com> wrote in message news:<mailman.2088.1093052072.5135.python-list at python.org>...
>>>By what kind of black magic would setting the property __synchronized__ to
>>>True would make that function synchronized ? And how can I define my own
>>>decorators then ?
>>There would be two kinds of decorators. Those that are simply
>>informative (like __author__ or __version__), and those that have
>>side-effects (like __metaclass__, __synchronized__, __automethods__,
>>etc.). Those with side-effects would be implemented as special functions...
>> def synchronized(func, trueOrFalse):
>> __decorator__ = True
>> __author__ = 'Billy Batson'
>> __version__ = '0.1'
>> # perform the synchronized operation on func...
> How would the parser know the difference between informative function
> variables like "__author__" and your special side-affecting function
In this proposal, the "side-effecting" functions would all be decorated
with "__decorator__ = True". So the interpreter would tell the
difference that way: for any given attribute __xxx__, if no function
exists with the name xxx and which also defined __decorator__ = True,
then xxx would be considered informational only.
Whether or not this idea has merit, it is too different than what is
seriously being considered to have a chance of being adopted. However
there is a compromise that is much more consistent with the current
decorator proposals yet doesn't require any new syntax.
The idea is that we mirror the __metaclass_ syntax, and introduce a new
magic variable __features__ which takes as its value a tuple of
""" This is a docstring. """
__features__ = synchronized, returns(None)
# function body goes here
The decorators would be located/resolved/applied as in the popular
More information about the Python-list