[ python-Bugs-1089978 ] exec scoping problem

[SourceForge.net]

Bugs item #1089978, was opened at 2004-12-22 12:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec scoping problem

Initial Comment:
Python 2.3.3 (#1, Oct 18 2004, 16:10:24) 
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] 
on linux2

Using exec on a code object with an "in ..." statement to specify locals 
and globals does not appear to set the globals for any code objects 
called by the exec'd code object.

As a workaround, I can exec a file object containing the relevant code 
objects and the scope appears to work, although the following issues are 
noted (these are possibly separate bugs, but all demonstrated by the 
attached... let me know if you'd like separate bugreport submissions, but 
I figured it was easiest to start with one in case I'm way off base in some 
fundamental way).

1. exec won't process an opened .pyc file, only a .py file.  However, the 
module's __file__ attribute will specify the .pyc or the .py, depending 
on which one is more recent.  This forces me to reset the extension to 
.py at all times.  It also means that if I use this technique I must ensure 
that the .py is always available relative to the .pyc.

2. The exec'd file needs the addition of a "if __name__ == '__main__'" 
to invoke the functionality I want.  This makes sense for exec'ing a 
file, but because I'm forced to exec the file to get globals scoped as I 
wanted, rather than using the code object, I am then limited to that 
single function invocation for any __name__ == "__main__" 
invocation of the file.

3. Specifying "in locals()" for the code object invocation has no 
adverse (or positive) effect, but specifying it for the file object seems 
to cause the interpreter to recurse the *current* file, not the exec'd file 
(this is Test #5 in the attachment).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470