[Python-Dev] def ... decorate

[Roman Suzi]

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 p_statement_expr:
>        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