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

[Ka-Ping Yee]

On Wed, 31 Mar 2004, Guido van Rossum wrote:
> > 	>>> [decorator]
> >
> > Will it type ... and wait for you to say more?  Or will it evaluate the
> > single-element list whose element is the value of the variable ``decorator''
> > and print the result?
>
> The latter.  You can't add a decorator to a top-level function in
> interactive mode unless you put it inside an if.

This discussion is turning in a direction that alarms me.

Guido, i beg you to reconsider.  Up to this point, we've all been
talking about aesthetics -- whether it's prettier to have the list
of decorators here or there, reads more naturally, visually suits
the semantics, and so on.

Putting the [decorator] on a separate line before the function
changes the stakes entirely.  It sets aside real functional issues
in favour of aesthetics.  Being enamoured with the way this syntax
*looks* does not justify functionally *breaking* other things in
the implementation to achieve it.

Consider the arguments in favour:

    1.  Decorators appear first.
    2.  Function signature and body remain an intact unit.
    3.  Decorators can be placed close to the function name.

These are all aesthetic arguments: they boil down to "the appearance
is more logical".  Similar arguments have been made about the other
proposals.

Consider the arguments against:

    1.  Previously valid code has new semantics.
    2.  Parse tree doesn't reflect semantics.
    3.  Inconsistent interactive and non-interactive behaviour. [*]
    4.  Decorators can be arbitrarily far away from the function name.

These are all functional arguments, with the exception of 4.  People
are pointing out that the way Python *works* will be compromised.

Putting the [decorator] on a separate preceding line:
    1. violates a fundamental rule of language evolution,
    2. makes it impossible to write an unambiguous grammar for Python, and
    3. stacks the odds against anyone trying to learn decorators.

I don't think there is any dispute about functionality.  Everyone
agrees that the interactive interpreter should reflect non-interactive
behaviour as much as possible; everyone agrees that previously valid
code should not change semantics; everyone agrees that the parse tree
should reflect the semantics.  Your responses to these points have been
of the form "Well, it's not *so* bad.  Look, we can hack around it..."

Those aren't positive arguments.  Those are excuses.

Aesthetic and functional arguments are at two entirely different scales.
To persist in finding excuses for one option because it is subjectively
good-looking, while setting aside objective functional deficiences, is
outside the bounds of reason.

Special cases aren't special enough to break the rules.

Please, i implore you, consider a different option on this one.

Thanks for reading,



-- ?!ng


[*] Please don't say "Oh, the interactive and non-interactive modes are
inconsistent already."  That's not a reason to make it worse.  Having
the interactive interpreter close an "if:" block when you enter a
blank line doesn't make "if:" totally unusable.  But interpreting
decorators inconsistently fails in a way that the decorator doesn't
work at all, and provides no hint as to how you would make it work.

This is especially bad since decorators are a weird and wonderful
feature and people are going to have to experiment with them in the
interactive interpreter as part of the learning process.  Every such
inconsistency makes Python harder to learn, and in particular this
will make decorators especially painful to learn.