[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