[Guido]
... BTW, while Alex has shown that a generator function with no free variables runs quite fast, a generator expression that uses variables from the surrounding scope will have to use the nested scopes machinery to access those, unlike a list comprehension; not only does this run slower, but it also slows down all other uses of that variable in the surrounding scope (because it becomes a "cell" throughout the scope).
[Tim]
The implementation could synthesize a generator function abusing default arguments to give the generator's frame locals with the same names.
Yes, I think that could work -- I see no way that something invoked by the generator expression could possibly modify a variable binding in the surrounding scope. <thinks> Argh, someone *could* pass around a copy of locals() and make an assignment into that. But I think we're already deprecating non-read-only use of locals(), so I'd like to ban that as abuse. --Guido van Rossum (home page: http://www.python.org/~guido/)