Alternative decorator syntax decision

[Paul Morrow]

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
> variables?
> 

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 
decorators...

     def foo():
        """ This is a docstring. """
        __features__ = synchronized, returns(None)
        # function body goes here

The decorators would be located/resolved/applied as in the popular 
proposals.