[Python-Dev] variable name resolution in exec is incorrect

[Colin H]

Thanks for the details on why the observed behaviour occurs - very
clear. My only query would be why this is considered correct? Why is
it running as a class namespace, when it is not a class? Is there any
reason why this is not considered a mistake? Slightly concerned that
this is being considered not a bug because 'it is how it is'.

A really good reason why you would want to provide a separate locals
dictionary is to get access to the stuff that was defined in the
exec()'d code block.  Unfortunately this use case is broken by the
current behaviour.  The only way to get the definitions from the
exec()'d code block is to supply a single dictionary, and then try to
weed out the definitions from amongst all the other globals, which is
very difficult if you don't know in advance what was in the code block
you exec()'d.

So put simply - the bug is that a class namespace is used, but its not a class.

On 26/05/2010 13:51, Nick Coghlan wrote:
> On 26/05/10 19:48, Mark Dickinson wrote:
>> This is a long way from my area of expertise (I'm commenting here
>> because it was me who sent Colin here in the first place), and it's
>> not clear to me whether this is a bug, and if it is a bug, how it
>> could be resolved. What would the impact be of having the compiler
>> produce 'LOAD_NAME' rather than 'LOAD_GLOBAL' here?
>
> exec with a single argument = module namespace
> exec with two arguments = class namespace
>
> Class namespaces are deliberately exempted from lexical scoping so
> that methods can't see class attributes, hence the example in the
> tracker issue works exactly as it would if the code was written as a
> class body.
>
> class C:
> y = 3
> def execfunc():
> print y
> execfunc()
>
> With this code, y would end up in C.__dict__ rather than the module
> globals (at least, it would if it wasn't for the exception) and the
> call to execfunc fails with a NameError when attempting to find y.
>
> I know I've closed other bug reports that were based on the same
> misunderstanding, and I didn't understand it myself until Guido
> explained it to me a few years back, so suggestions for improving the
> exec documentation in this area would be appreciated.