[Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 20 Jun 2002 07:54:42 -0700
Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: It's the future for generators
Initial Comment:
"from __future__ import generators" should no longer
be required in 2.3a1. Such stmts should also be
removed from the Python library (there's a script
under Tools to automate this).
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2002-06-20 10:54
Message:
Logged In: YES
user_id=31435
Thanks for the reminder! There was still a generator future
stmt in test_enumerate.py, which I just got rid of. I don't
know of any other glitches here, so finally closing this.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 03:59
Message:
Logged In: YES
user_id=80475
Can this be closed?
The library is free of from __future__ generators and the
core doesn't require it now.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:18
Message:
Logged In: YES
user_id=6380
It's not too late! Neil hasn't checked it in yet.
Neil, would you be willing to change your patch so that it
disables the yield keyword using #ifdef rather than by
erasing all of the code?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:59
Message:
Logged In: YES
user_id=31435
Na, you should read me as saying I don't know how to write
the kinds of docs you want. I didn't do the parser changes
here, so if you think there's something predictable and
useful to be said here, you're the one to say it.
Keeping at least one example around under an "#if 0" sounds
like an excellent idea. The last time I implemented a
future gimmick, it was spread around in so many places that
the only sane way to proceed was to search for "the other"
future gimmick that happened to be implemented already.
But doing that kind of search again is the only sane way I
know to get rid of the future-generator business now too.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39
Message:
Logged In: YES
user_id=6380
Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.
The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.
But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22
Message:
Logged In: YES
user_id=31435
The internal future machinery has changed every time we've
added a new future gimmick. So there's really nothing to
be said other than to scour the source code looking for now-
obsolete "stuff". For example, it's possible that the
kinds of parser changes made for "yield" will never happen
again, and, even if they do, I think it's impossible to
predict where and how the parser will need to be unchanged.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13
Message:
Logged In: YES
user_id=6380
There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34
Message:
Logged In: YES
user_id=31435
Neil, if you don't enjoy using the patch system for
straightforward stuff like this, don't feel compelled to
use it. That is, just check it in.
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04
Message:
Logged In: YES
user_id=35752
The attached patch removes the "yield is an optional keyword"
hacks from the parser. It's not a complete fix for this
bug though.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470