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

[Barry Warsaw]

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