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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4