[Jeremy] > >> The nested scopes rules don't kick in until you've got one > >> function nested in another. The top-level namespace is treated > >> differently that other function namespaces. If a function is > >> defined at the top-level then all its free variables are globals. > >> As a result, the old rules still apply. > > GvR> This doesn't make sense. If the free variables were truely > GvR> considered globals, the reference to x would raise a NameError, > GvR> because the exec doesn't define it at the global level -- it > GvR> defines it at the local level. So apparently you are > GvR> generating LOAD_NAME instead of LOAD_GLOBAL for free variables > GvR> in toplevel functions. Oh well, this does the job! [Jeremy] > Actually, I only generate LOAD_NAME for unoptimized, top-level > function namespaces. These are exactly the old rules and I avoided > changing them for top-level functions, except when they contained a > nested function. Aha. > If we eliminate exec without "in," this is yet another problem that > goes away. But that's for another release... That will probably get a lot of resistance from some category of users! So it's fine for now. Thanks, Jeremy! Great job! --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