[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)

Ka-Ping Yee python-dev at zesty.ca
Wed Mar 31 17:44:24 EST 2004


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.



More information about the Python-Dev mailing list