Nick Coghlan <ncoghlan at gmail.com> writes: > Joachim B Haga wrote: >> There seem to be an inconsistency in the handling of local scopes in >> exec. [...] >> >> The intermediate scope is searched for the variable name if the third >> argument to exec() is locals(), but not if it is locals().copy(). > > What actually matters is whether or not the first and second scope are > the same dictionary or not. > > If they're different, then the supplied local scope is treated as > equivalent to a class definition scope, and hence won't participate in > lexical scoping. If they're the same (which happens implicitly if the > second one is omitted) then they're treated as a module scope (and hence > written values are visible as globals inside any defined functions). Ok, thank you for the explanation. > Since changing this would break class definitions, that ain't going to > happen. Suggestions for how to explain the behaviour more clearly in the > exec() documentation probably wouldn't hurt though. I don't quite see how exec() affects the class definition syntax? Anyhow, I definitely agree that this should be documented. I suggest the following (condensed from your explanation): -If provided, /locals/ can be any mapping object. +If provided, /locals/ can be any mapping object. It is treated as equivalent to a class definition scope, and hence does not participate in lexical scoping. -- Joachim B Haga
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