__metaclass__ and __author__ are already decorators

[Paul Morrow]

Paolo Veronelli wrote:

> 
> 
> Paul Morrow wrote:
> 
>> Paolo Veronelli wrote:
>>
>>>
>>>
>>> Paul Morrow wrote:
>>>
>>>> Thinking about decorators, and looking at what we are already doing 
>>>> in our Python code, it seems that __metaclass__, __author__, 
>>>> __version__, etc. are all examples of decorators.  So we already 
>>>> have a decorator syntax.  What is the compelling reason to invent a 
>>>> new one?  And if we do, what's to become of the old one?
> 
> 
>>>
>>>     Thanks for pointing out another unpythonicity. Paolino
>>>
>>
>> Is that what I did?  Isn't assigning values to __xxx__ attributes 
>> pythonic?  
> 
> 
> Really but instructing the interpreter with assigning to special 
> attributes is not a well classified operation:
> 
> __author__ & company are just settable/gettable (the don't instruct the 
> interpreter)  this is surface  level.
> 
> __getitem__ (in ex)  instruct the intepreter on how to parse [] sintax 
> (am I wrong?).So __lt__ and the alike :that's what I call a syntactic 
> level.This is more or less well defined (and so pythonic):operators can 
> be defined like this.
> 
> __metaclass__  doesn't seem to be placed in the first two categories.It 
> instruct the interpreter on a deeper level (in my vision),an actual 
> level which I think is well related with decorator level.If I am 
> right,this speciality of an only attribute makes it unpythonic.It has to 
> be part of a class
> of attributes ,which would be nice to be  populated just (at least) to 
> make its instructing position clearer.

And this would give us more attributes in that (__metaclass__) category. 
  But there mere existence of one such attribute makes similar things 
pythonic, I believe.

__author__, __getitem__, and __metaclass__ may be at different 'levels' 
as you put it, but they are all in the same specification 'dimension' 
--- the meta information dimension.  And this is the same dimension that 
decorators exist in.