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

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