[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