It's the future for generators

[tim-one]

BPO	495978
Nosy	@gvanrossum, @tim-one, @nascheme, @rhettinger
Files	undo_yield_hack.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tim-one'
closed_at = <Date 2002-06-20.14:54:42.000>
created_at = <Date 2001-12-21.22:17:39.000>
labels = ['interpreter-core']
title = "It's the future for generators"
updated_at = <Date 2002-06-20.14:54:42.000>
user = 'https://github.com/tim-one'

bugs.python.org fields:

activity = <Date 2002-06-20.14:54:42.000>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2001-12-21.22:17:39.000>
creator = 'tim.peters'
dependencies = []
files = ['271']
hgrepos = []
issue_num = 495978
keywords = []
message_count = 10.0
messages = ['8431', '8432', '8433', '8434', '8435', '8436', '8437', '8438', '8439', '8440']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'tim.peters', 'nascheme', 'rhettinger']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue495978'
versions = ['Python 2.3']

[tim-one]

"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).

[nascheme]

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.

[tim-one]

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.

[gvanrossum]

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?

[tim-one]

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.

[gvanrossum]

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. :-)

[tim-one]

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.

[gvanrossum]

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?

[rhettinger]

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.

[tim-one]

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.