At 03:43 PM 3/30/04 -0800, Guido van Rossum wrote:
> > 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.)
> > 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. 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4