[Python-Dev] PEP 318 - generality of list; restrictions on
elements
Phillip J. Eby
pje at telecommunity.com
Wed Mar 10 13:15:16 EST 2004
At 08:56 AM 3/10/04 -0800, Guido van Rossum wrote:
> > That still leaves the question for what *is* allowed within the
> > brackets. AFAICT, the options are
> >
> > * A single identifier (which must be a callable)
> >
> > * Comma-separated list of identifiers (which must be callables)
> >
> > * Arbitrary expression (which must produce a sequence of callables)
>
>The latter. I previously mentioned a use case for allowing a function
>call (or class constructor) here.
>
> > BTW, have we agreed on the order in which decorators will be applied?
>
>I think I've said in the past left-to-right, but since we're talking
>function application here, right-to-left might also work.
I think the reason you said so in the past, was because normally Python
expressions go left-to-right. That is, Python always evaluates things in
the order you see them. Even in 'x(y,z)', x is evaluated, then y, then z.
> And it's
>also possible that decorators are (by convention) commutative, making
>it a wash. It's a concern that there's no clear reason to prefer one
>order! We'll have to come up with some use cases.
The way I see it, left-to-right helps reading what's happening to the
function. For example:
def foo(cls,...) [contract(blah), classmethod]:
...
clearly says that a contract wrapper is being applied to foo, and then it
is being made a classmethod.
If the order were the other direction, it would force you to read
right-to-left in order to know what's going to happen to the function.
So, I vote for left-to-right on the grounds of "readability counts". :)
(Which is also why I favor decorators after the arguments; 'foo(...)' at
least looks something like the way it'll be called, while foo[...](...)
bears no resemblance.)
More information about the Python-Dev
mailing list