How does IDLE clean up it's local scope on startup? By that I mean the following. When you start IDLE and do a dir() you get the following: Python 2.2.2 (#1, Oct 28 2002, 17:22:19) [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2 Type "copyright", "credits" or "license" for more information. GRPC IDLE Fork 0.8.9
dir() ['__builtins__', '__doc__', '__name__']
Only three items are returned by dir(), just like in the regular Python interpreter. Now I know how IDLE sets this up in its code, but I can't seem to achieve the exact same results with PyCrust. And when I add a print statement to the IDLE source code (PyShell.py): class ModifiedInterpreter(InteractiveInterpreter): def __init__(self, tkconsole): self.tkconsole = tkconsole locals = sys.modules['__main__'].__dict__ print locals.keys() InteractiveInterpreter.__init__(self, locals=locals) self.save_warnings_filters = None I can see that locals contains a bunch of stuff (well, one extra item when you run idle.py, and a bunch of stuff when you run PyShell.py), similar to what I see in PyCrust. So where does it all go by the time IDLE is up and running? Where does locals get "cleaned up"? Every one of my hunches has lead to me down a dead end. I give up! Please help. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
How does IDLE clean up it's local scope on startup? By that I mean the following. When you start IDLE and do a dir() you get the following:
Python 2.2.2 (#1, Oct 28 2002, 17:22:19) [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2 Type "copyright", "credits" or "license" for more information. GRPC IDLE Fork 0.8.9 ^^^^ ^This is a clue.
dir() ['__builtins__', '__doc__', '__name__']
Only three items are returned by dir(), just like in the regular Python interpreter. Now I know how IDLE sets this up in its code, but I can't seem to achieve the exact same results with PyCrust. And when I add a print statement to the IDLE source code (PyShell.py):
class ModifiedInterpreter(InteractiveInterpreter):
def __init__(self, tkconsole): self.tkconsole = tkconsole locals = sys.modules['__main__'].__dict__ print locals.keys() InteractiveInterpreter.__init__(self, locals=locals) self.save_warnings_filters = None
I can see that locals contains a bunch of stuff (well, one extra item when you run idle.py, and a bunch of stuff when you run PyShell.py), similar to what I see in PyCrust. So where does it all go by the time IDLE is up and running? Where does locals get "cleaned up"? Every one of my hunches has lead to me down a dead end. I give up! Please help.
IDLE doesn't use these locals any more; they're decoys. The GRPC version runs the interpreter in a subprocess and the subprocess is more careful. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wednesday 13 November 2002 02:00 pm, Guido van Rossum wrote:
IDLE doesn't use these locals any more; they're decoys. The GRPC version runs the interpreter in a subprocess and the subprocess is more careful.
Ah. I suspected that, but didn't understand the subprocess code enough to figure that out. Thanks. Here is my real problem. I used to just pass a regular dictionary to code.InteractiveInterpreter, which worked well enough. But I just discovered an issue with pickling in the PyCrust shell, illustrated below: Welcome To PyCrust 0.8 - The Flakiest Python Shell Sponsored by Orbtech - Your source for Python programming expertise. Python 2.2.2 (#1, Oct 28 2002, 17:22:19) [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import pickle def foo(): ... pass ... pickle.dumps(foo) Traceback (most recent call last): File "<input>", line 1, in ? File "/usr/local/lib/python2.2/pickle.py", line 978, in dumps Pickler(file, bin).dump(object) File "/usr/local/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 519, in save_global raise PicklingError( PicklingError: Can't pickle
: it's not found as __main__.foo
So I decided to switch to using sys.modules['__main__'].__dict__, which eliminated the pickling error, but introduced a bunch of clutter in the local namespace. Any suggestions? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
Here is my real problem. I used to just pass a regular dictionary to code.InteractiveInterpreter, which worked well enough. But I just discovered an issue with pickling in the PyCrust shell, illustrated below:
Welcome To PyCrust 0.8 - The Flakiest Python Shell Sponsored by Orbtech - Your source for Python programming expertise. Python 2.2.2 (#1, Oct 28 2002, 17:22:19) [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import pickle def foo(): ... pass ... pickle.dumps(foo) Traceback (most recent call last): File "<input>", line 1, in ? File "/usr/local/lib/python2.2/pickle.py", line 978, in dumps Pickler(file, bin).dump(object) File "/usr/local/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 519, in save_global raise PicklingError( PicklingError: Can't pickle
: it's not found as __main__.foo So I decided to switch to using sys.modules['__main__'].__dict__, which eliminated the pickling error, but introduced a bunch of clutter in the local namespace. Any suggestions?
Remove the clutter. This probably means having a very minimal "real" main program. IDLE does this by putting all the real code in the "run" module, and bootstrapping the subprocess as follows: python -c "__import__('run').main()" This is roughly equivalent to executing import run run.main() except that it doesn't create a variable 'run'. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Patrick K. O'Brien