A decorator syntax not yet mentioned (I think!)

Steven Bethard steven.bethard at gmail.com
Wed Aug 11 18:33:01 EDT 2004


Michael Sparks <michaels at rd.bbc.co.uk> wrote in message news:<cfdh4q$kpm$1 at nntp0.reith.bbc.co.uk>...
> The only downside I can see is that it might not be 100% obvious that it
> relates to the following function to newcomers to python.

This is a downside, but as far as I can tell, it's a downside of all
proposals that place the decorator declaration before the function. 
Since it looks like we're stuck with pre-def decorators, I wouldn't
really worry about this issue too much.

> In a syntax highlighted editor that also looks *alot* cleaner than
> beforehand. IMO, it also looks slightly cleaner than the @version - for
> one very, very simple reason - if you have a very big decorator block,
> for whatever reason, the "def" stands out clearly so you can skim where
> the function starts - even without syntax highlighting.

This is a great point.  I definitely agree -- it's much easier to find
the def than even the @ solution.  Compare:

@grammarrule('statement : expression')
@versioninfo("Added in 2.4")
@deprecated
@typeinfo(None)
def p_statement_expr(self, p):
    print p[1]

vs.

decorate:
    grammarrule('statement : expression')
    versioninfo("Added in 2.4")
    deprecated
    typeinfo(None)
def p_statement_expr(self, p):
    print p[1]

Of course, you could allow the same thing with '@':

@:
    grammarrule('statement : expression')
    versioninfo("Added in 2.4")
    deprecated
    typeinfo(None)
def p_statement_expr(self, p):
    print p[1]

But this looks really cryptic -- unlike 'decorate', '@' doesn't really
read as anything.  You probably know that the '@' "applies" to all the
lines below it, but unless you already know what '@' means, you
probably have no idea how it "applies".  The keyword version seems
much clearer on this point.


I know there were complaints before about this sort of indentation,
but I couldn't find them in python-dev and the comments in the wiki
don't discuss this in any detail.  Can anyone tell me why this
indentation syntax was dispreferred?  Specifically, I'm interested in
why this is so drastically different from the other paired blocks:
if/elif/else, try/except, try/finally, etc.  Also, there's a comment
in the wiki that says that there are technical problems with the
grammar if a block *starts* with an optional part.  Does this not
apply to the @ case (which also starts a block with an optional part)?

Thanks,

Steve



More information about the Python-list mailing list