> [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/)
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