[Python-Dev] PEP 318: Decorators last before colon

[Guido van Rossum]

> > > Hm.  So if we reversed the order so that the outermost
> > > decorators (such as classmethod) come first in the list, would
> > > that sway you to relent in favor of decorators-after-arguments?
> >
> >Not really, because they're still hidden behind the argument list.
> 
> Because:
> 
> 1) it won't be on the same line if there are lots of arguments
> 2) nobody will read past the argument list
> 3) other
> 4) all of the above
> 5) none of the above
> 
> (Not trying to change your opinion; I just think the answer to this should 
> go in the PEP.)

1&2, mostly.

> > > I don't like the reversed order, but I think I'd be a lot more
> > > comfortable with explaining that relatively minor semantic oddity to
> > > other developers than I would be with trying to explain the major
> > > syntactic oddity (relative to the rest of the Python language) of
> > > decorators-before-def.
> >
> >OTOH to C# programmers you won't have to explain a thing, because
> >that's what C# already does.
> 
> Correct me if I'm wrong, but I don't believe C# attributes have
> anything like the same semantics as Python decorators; in fact I
> believe they may be more akin to Python function attributes!  So,
> even to a C# programmer, I'll have to explain Python's semantics.

Yes of course, but the basic idea that this specifies attributes
should be clear to them.  You always have to explain Python's
semantics -- even assignment is deeply different!

> Indeed, the C# syntax has things like this:
> 
> [ReturnValue: whatever(something)]
> 
> to specify what the attributes apply to, and they can be applied to
> parameters, the return value, the module as a whole, etc.  But I
> don't want to get too far off-topic.
> 
> By the way, you didn't mention whether it's okay to put the decorators on 
> the same logical line, e.g.:
> 
> [classmethod] def foo(bar,baz):
>      # body goes here
> 
> If the rationale here is that we're copying C#, I'd think that it
> should be permissible, even though it looks a bit ugly and tempts me
> to indent the body to align with the function name.

This is much harder to do with the current parser.  (My plan would be
to tie the list expression and the function definition together in the
code generating phase, just like doc strings.)

--Guido van Rossum (home page: http://www.python.org/~guido/)