[Python-Dev] def ... decorate (original) (raw)

Jack Diederich jack at performancedrivers.com
Fri Aug 13 23:31:00 CEST 2004

On Fri, Aug 13, 2004 at 02:51:37PM -0500, Skip Montanaro wrote:

I understand that not everyone will like every idea and that in this particular arena it seems that no one idea is acceptable to everyone, but can we return to my proposal and discuss its pros and cons? I didn't pick the example out of thin air. I cast an existing example from c.l.py in this form (thus the function name and somewhat unusual collection of decorator names). The only thing I added besides the syntax change was to identify where I thought the docstring should go. def pstatementexpr: staticmethod grammarrule('statement : expression') version("Added in 2.4") deprecatedmethod type(None) decorate (self, p): """docstring here""" print p[1] I understand that it has obvious weaknesses as well: * It separates the function name from its parameter list. That does allow us to aboid parsing ambiguities though. This is huge, it would mean two ways to do it. When I want to decorate the function with '@' I add an extra line above the existing definition. With this suggestion I have to pick the line apart and shuffle stuff around. Guido has said being able to add/remove a decorator should be as simple as cut/pasting a line and I agree.

* It can't readily be extended to class definitions, though the demand for that seems minor and mostly argued for symmetry reasons. Class decorators are pretty important to me. I would replace most of my meta class usages with decorators. I care enough I spent two days writing a patch and fishing through the bowels of compile.c (plug plug).

A group of points

-Jack

More information about the Python-Dev mailing list