[Python-Dev] Re: __metaclass__ and __author__ are already decorators

"Martin v. Löwis" martin at v.loewis.de
Sun Aug 22 18:53:47 CEST 2004


Paul Morrow wrote:
>>   @foo
>>   def bar():self
>>
>> might cause bar *not* to be a function. This can only be understood
>> if you don't think of decorators as kind of attribute.
>>
> 
> Another recipe for disaster.  If foo can change bar into something that 
> is no longer a function, then you can create defects that are 
> unacceptably hard to find.  Never use that pattern either, if there is a 
> less 'fancy' alternative (and there almost always will be).

Yet, this is what happens for staticmethod and classmethod: the result
of applying the decorator will cause bar not to be a function anymore
(but a staticmethod or a classmethod, respectively). There is no
alternative for this.

> No, 'how' magic works (details of the innerworkings of the interpreter) 
> isn't necessary for most programmers to understand (unless of course 
> you're working on the interpreter or in some other way trying to extend 
> the Python system).  They only need to know what each type of magic does 
> and how to use it properly.  That needs to be thoroughly documented. But 
> the implementation should only be of interest to the low-level 
> developers of the Python system (with rare exceptions).

In the case of decorators, atleast anybody designing one should know how
this works. They are intentionally extensible, so many more than the
Python developers proper will need to know how decorators work.

> Well, define magic.  If you mean automatic behavior, then I strongly 
> disagree. You need the system to do things automatically for you, 
> otherwise you're writing in nothing more than assembly language.  What 
> kind of magic are you referring to?

Your proposal specifically: use __foo__ for decorators, instead of
@foo. You haven't actually specified how this works, but merely asserted
that it will work, and (apparently) declared important details as
irrelevant implementation details.

Regards,
Martin


More information about the Python-Dev mailing list