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

Gareth McCaughan gmccaughan at synaptics-uk.com
Fri Aug 13 20:06:13 CEST 2004

On Friday 2004-08-13 18:52, Werner Schiendl wrote:

[Skip] > > def pstatementexpr: > staticmethod > grammarrule('statement : expression') > version("Added in 2.4") > deprecatedmethod > type(None) > decorate (self, p): > """docstring here""" > print p[1] >

was the following suggested already? (don't think so): def pstatementexpr(self, p): staticmethod grammarrule('statement : expression') version("Added in 2.4") deprecatedmethod type(None) body: """docstring here""" print p[1]

So you see "def name(args):" followed by what looks at first glance like a function body ... and then it turns out N lines later that it was really a set of decorators. Surely if this sort of two-suite approach is going to be used, there is only one sane way to do it (modulo choice of keyword):

def p_statement_expr(self, p):
    """docstring goes here"""
    print p[1]
decorated:
    staticmethod
    grammarrule('statement : expression')
    version("Added in 2.4")
    deprecatedmethod
    type_(None)

which keeps the arguments with the function name, keeps the body right after the name and arguments, and puts the decoration after the body which corresponds with the order in which things actually happen (though not necessarily the best order for understanding the code).

Another merit to "post-position" decoration (which applies here, where decoration is after the body, and also to the original after-arglist proposal) is that it's fairly obvious what order the decorators are applied in: the two criteria are order of appearance and order of proximity to the thing the decorators seem visually to be attached to, and those agree. For the @foo syntax they don't.

I actually quite like this. It seems more Pythonic than the @foo proposal. Its obvious problem is that it involves something that looks at first glance like an ordinary suite of statements or expressions, but whose interpretation is substantially different. At least the @foo proposal avoids that.

I'm +1 on the original []-after-def proposal (which is to be expected, since IIRC I was the first person to propose it), +0.5 on what I've suggested above, +0 on Guido's @foo, and a big hairy -1 on the weird distortions of "def" I'm replying to :-).

-- g

More information about the Python-Dev mailing list