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

Josiah Carlson jcarlson at uci.edu
Sat Aug 14 00:12:14 CEST 2004

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] Roman Suzi seemed to like it, given his "Bingo!" remark, but felt immediately moved to alter it with no explanation. Josiah replied to that with "Oh god no". It went downhill from there, to the point where Raymond posted a sarcastic note about using reST and XML. I don't know if Roman's immediate modification implies his "Bingo!" was just lukewarm. I have no idea what Josiah was saying "Oh god no" to.

Mostly the separating the function name from the arguments.

* It doesn't put the cart before the horse by introducing the decorators before the def.

Great.

* It doesn't add an extra level of indentation to the function body.

Great.

* It leaves '@' alone, implying that at some point in the future Guido (if he so chooses) proclaim that "'@' will never be used in Python at the start of a line, so it is free for external tools to use as a markup character".

!|&-+* also leave the '@' alone. I think that if it werent for '|' being mistakable for I,l or 1, it would already have been chosen.

* It looks more like current Python block structure (at least to me) than the @-syntax proposal.

Check my P.S. at the end.

I understand that it has obvious weaknesses as well:

* It separates the function name from its parameter list. That does allow us to avoid parsing ambiguities though.

Separating the argument list from the function name is enough to kill it for me.

* It can't readily be extended to class definitions, though the demand for that seems minor and mostly argued for symmetry reasons.

Why can't it be extended?

class decorated_class: decorators decorate: #or (subcls1, subcls2) before the colon with subclasses "docstring" body

Personally, I don't desire decorators for classes for symmetry reasons, I desire it to replace metaclasses, at least in those things that I could conceivably want metaclasses to do.

One or more of those weaknesses may well be a show stopper. There may be other pros and cons I'm missing. That's fine, but can people please be specific in their criticism? I purposely posted twice, once here and once on c.l.py, to avoid random smartass responses on c.l.py from leaking over to python-dev. Little did I realize I need not have worried about that.

My major issue is that I think we should be making a small change to the language. I believe that any change that could be considered a large change should be avoided.

Introducing an additional block structure to specify decorators seems to be a large change.

Separating the name of a function from the arguments seems to be a large change.

Other proposals attempt to indent function definitions inside decorators, which is also a large change (which also destroy readability).

Let us try to keep the change small. Sound reasonable?

P.S. One could make the claim that assigning directly to slots and metaclass are a bit of magic that could have been avoided with proper decorators (or even that metaclasses could have been avoided with decorators).

@metaclass(metaclass) @slots("slot1", "slot2") class classname: #etc.

Heck, it almost looks like what we already have in Python when we do the following...

class classname(object): @metaclass(metaclass) #or @metaclass_like_decorator @slots("slot1", "slot2") @doc("docstring") #etc.

Goodness, there's a syntax to rule them all. Not only does it kind of look like what we already have, but it is further extendable with other name decorators.

Choose any @ replacement if desireable.

More information about the Python-Dev mailing list