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

Roman Suzi rnd at onego.ru
Sat Aug 14 00:05:08 CEST 2004

On Fri, 13 Aug 2004, 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] 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.

Well, your example lead me to my syntax and I liked it very much at the moment.

I have no idea what Josiah was saying "Oh god no" to.

Now it seems less wonderful to me, because I forgot about decorating classes.

class lalalal: decor from (A,B): @definition

doesn't have properties I'd liked to see. Same applies to Skip's syntax.

It seems to satisfy most obvious requirements:

* It's clear from the start what function we are modifying, and you know early on that it's not your grandfather's Oldsmobile, err... function. * All decorators are listed up near the top (parseable I think using grammar bits requiring one decorator per line, similar to the current @-syntax). * It doesn't put the cart before the horse by introducing the decorators before the def.

I agree with this.

* If someone looks at it and thinks, "WTF!", it's readily apparent they should seek help with the "def" or "decorate" keywords.

Ummm.... Me thinks it's much more important to facilitate those who write lots of code than those who looks at it sheepishly (sp?)

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

* 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".

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

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. * It introduces a new 'decorate' keyword, though I think it could sneak by as a pseudo-keyword like 'as'.

... or no keyword at alll, as some suggested.

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

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.

IMO, "decorate" is too wordy. "dec" is associated with "decimal", so your proposal has no chance to fly :-( And mine too as Josiah showed above.

This @discussion reminds me of inline-if one. With the difference that at that time GvR did not favor ANY syntax and now he favors the @syntax. Lets tell to themselves that there are no better choices than @. Amen.

Skip

Sincerely yours, Roman Suzi

rnd at onego.ru == My AI powered by GNU/Linux RedHat 7.3

More information about the Python-Dev mailing list