[Python-Dev] Re: def ... decorate

[Gareth McCaughan]

On Friday 2004-08-13 18:52, Werner Schiendl wrote:
> [Skip]
> >
> >     def p_statement_expr:
> >         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 p_statement_expr(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