[Python-Dev] Call for defense of @decorators

Phillip J. Eby pje at telecommunity.com
Thu Aug 5 21:32:04 CEST 2004


At 04:17 PM 8/5/04 -0300, Gustavo Niemeyer wrote:
> > The ctypes package behaves similarly and would use decorators for the
> > same thing.  I imagine that other runtime/language bridges would also
> > benefit from similar techniques (Jython, IronPython, Python.NET,
> > JPython.. or whatever else).  I can also imagine it being used for
> > things like XML-RPC, SOAP, Apple Events, COM, etc. in a similar manner.
>
>Is this something good? I mean, having function wrappers all
>around the place? Wouldn't it be introducing unobvious code (magic?)
>in packages which are working fine as they are?
>
>Should I just throw away my t-shirt with the "zen of python" text? :-)

This special syntax would be entirely unnecessary if Python function 
definitions (other than lambda) were expressions.  Apart from that 
syntactic issue, decorators are nothing new, and people already use them.

Is it better to bury the magic *after* the function body, or put it 
before?  In every other programming language I know of where functions are 
first class objects, one applies decorators  *before* the function body.

The advantage of a specialized decorator syntax over simply wrapping 
decorator calls around function bodies, is that it's possible to reduce the 
nestedness of the expression, e.g.:

     @binding.Make(uponAssembly=True)
     @events.taskFactory
     def some_method(self):
         ...

versus:

     binding.Make(events.taskFactory(
         def some_method(self):
             ...
         ),
         uponAssembly=True
     )

or today's:

     def some_method(self):
         ...
     some_method = 
binding.Make(events.TaskFactory(some_method),uponAssembly=True)

Given that '...' can be arbitrarily long, and "flat is better than nested", 
this looks like a net win for this style of programming.

Metaprogramming is an important part of Python, that has always been in 
Python and always should be.  Given that, it is better to have a visible 
syntax that precedes the function body, and this is the fundamental basis 
for the existence of PEP 318.






More information about the Python-Dev mailing list