[Python-Dev] PEP 318: Let's not give in to FUD (original) (raw)

Barry Warsaw barry at python.org
Fri Apr 2 14:08:56 EST 2004

On Fri, 2004-04-02 at 12:05, Jeremy Hylton wrote:

On Fri, 2004-04-02 at 08:24, Barry Warsaw wrote: > It may be nonsense, but it means something today. So it can't be > obvious that they're connected because today, they aren't.

Your original complaint was: "What are newcomers going to make of this?" Newcomers aren't going to be worried about the small change in semantics that decorator-before would entail, because they won't know the old semantics.

They already know the old semantics. If they were to encounter that syntax today, they'd know that Python throws away the results. If /I/ saw that construct in today's Python code, I'd start looking for side effects.

> If tomorrow this same code means something different, users looking at > the code will have to know what version of Python they're using, and > make sure it's the right one ("uh, how do I do that?"). If they were to > use decorator-before-def code in an older version of Python, the program > would be accepted but silently do the wrong thing.

I agree there's a risk here, but we've faced that kind of risk before. We used future statements for nested scopes, but only one version. If you're looking at code with free variables, you need to know whether it was written to run with or without nested scopes. Code written for one version will fail at runtime on the other. (It may or may not fail silently.)

Adding a future statement would make decorator-before-def slightly more acceptable. Adding a keyword to introduce decorator-before-def would make it slightly more acceptable. All-in-all, I still think decorator-before-colon is plenty readable and the more obvious of the two choices.

-Barry

More information about the Python-Dev mailing list