[Python-Dev] def ... decorate

Skip Montanaro skip at pobox.com
Fri Aug 13 21:51:37 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 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.  I have no
idea what Josiah was saying "Oh god no" to.

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.

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

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

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

Skip


More information about the Python-Dev mailing list