A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-March/043451.html below:

[Python-Dev] Possible resolution of generator expression variable capture dilemma

[Python-Dev] Possible resolution of generator expression variable capture dilemma [Python-Dev] Possible resolution of generator expression variable capture dilemmaGuido van Rossum guido at python.org
Wed Mar 24 08:30:08 EST 2004
> However, I'm suggesting something different. I'm *not* proposing to
> make it *local* to the loop -- its name will still reside in the
> enclosing namespace, and its value will still be available after the
> loop finishes. In fact, if it's not referenced from any nested scope,
> there will be no change in semantics at all.
> 
> What *will* change is perhaps best explained by means of the
> implementation, which is very simple. If the loop variable is
> referenced from a nested scope, it will be held in a cell. Now, on
> each iteration, instead of replacing the contents of the cell as a
> normal assignment would, we create a *new* cell and re-bind the name
> to the new cell.

If I had known Scheme 15 years ago I might have considered this -- it
is certainly an interesting approach.  I'll have to ponder this a lot
more before accepting it now; the potential consequences seem
enormous.  (It also pretty much forces this particular way of
implementing nested scopes.)

I think it's definitely out of the question before 3.0; it's too
subtle a change to too fundamental a construct.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list

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