Bug in execfile?

Fernando Perez fperez.net at gmail.com
Fri Aug 3 00:23:07 CEST 2007


Ian Clark wrote:

> Fernando Perez wrote:
>> Hi all,
>> 
>> (snip)
>> 
>> I'm really, really puzzled by this.  From reading the execfile() docs, I had
>> the hunch to change the call to:
>> 
>>     execfile(fname,{})
>> 
>> and now the problem disappears, so I can keep on working.
>> 
>> But I'm still very bothered by the fact that changing that first call 'if 0'
>> to 'if 1' has any effect on the later call to runscript().  That really
>> doesn't feel right to me...

[...]

> By default execfile works on the *current* namespace. So exec'ing a
> script that modified it's global namespace will also modify the global
> namespace of the calling module (see my first example). If you specify a
> dictionary then execfile will use that as the global and local (maybe)
> namespace of the file that it is running (hence the global namespace of
> the calling module stays in tact per the second example). That is why
> execfile(fname, {}) works for you, it doesn't pollute your current
> namespace. It uses a different namespace when calling the file then is
> being used by the calling module.

Right, it makes complete sense that the first execfile() call puts the symbols
in the global namespace, and that's why the failure disappears when calling
the runscript wrapper.  I just didn't think carefully enough, thanks.

> No idea why your function failed though. *shrug*

Yes, that still bothers me.  That a simple

def runscript(f): execfile(f)

won't work just like execfile would is, at the least, a bit puzzling to me.

Cheers,

f




More information about the Python-list mailing list