Fortunately, discovering pythonrun.c has helped tremendously. Along with
the other person's suggestion to look at the rename file, I've been able to
start working back into the guts of the interpreter from there. [I'll say,
compile.c is -not- the best place to start learning how Python works. ;)]
| > Second, the application needs to have multiple Python scripts running in
| > their own context. Not multi-threaded, but it may have multiple
...
| > appears that the only potential problem would be the 'sys' module; most of
| > the attributes there are okay since all the scripts will share stdin etc.,
| > and I could probably hack around to get things to work for the others...
| > but if there is any way to have something like an instantiation of sys for
| > each script...
|
| This is currently impossible. As you mention, for most built-in
| modules it won't be a problem if they are shared. For sys, sharing
| may be a problem, but it isn't easy to solve -- the interpreter looks
| in sys at various times, so you can change sys.stdout etc., but it has
| a static pointer that tells it where sys is. I may change this in a
| future release (and 1.2 will already contain a few things that make it
| easier), but at the moment, I think the best you can do is probably
| decide which elements of sys you want to keep per context, and then
| implement the context swapping yourself. Since you don't need
| threads, you have total control over which context you activate, so it
| isn't that much work to have a dictionary for each context that
| contains the values of sys.path, sys.std{in,out,err} and whatever else
| you want to preserve. (This is beginning to look like the Macintosh
| implementation of application switching, where when an app is
| activated its low memory globals are switched... :-)
Okay, this should work fine; the scripts aren't going to need to muck
around directly with the interpreter or OS anyway. And fortunately, if
anything does become a problem, I can just not let them do that.
Hopefully I can mostly avoid the Mac approach. ;)
| > And could there be any problems with this in any other modules? Do any
| > modules keep internal state variables that could cause independent scripts
| > to step on each other?
|
| I'd have to inspect each module in turn to answer that one. Off the
| top of my head, I'd say that most built-in modules are pretty sane and
| only provide functions (__builtin__, math, posix are definitely OK).
| There's a global in regex which has the current regular expression
| syntax (a bad idea and in the future I will make the syntax an
| optional parameter to the compile() function). The signal module
| definitely has lots of per-process state. The stdwin and X modules
| probably have some tables that are used in translating "raw" window
| pointers back to Python objects, but with some care these would
| probably be alright.
The scripts won't need signal or the GUI modules, so that shouldn't be a
problem. The regex module optionally allows you to compile a pattern and
then manually pass it in, right? Depending on the global can just be
marked as unsuported, if not completely taken out.
| Note that there is also context maintained by the UNIX process --
| e.g. although the posix module is safe, one context doing a chdir()
| will affect all other contexts!
The scripts don't get to mess with that stuff, too. :)
| > Third, is there any simple way to set things up so that the interpreter
| > will allow my program to keep a check on the scripts while they are
| > running? What I am thinking of is some kind of callback into my program it
| > can make when it checks for signals as per the sys.check_interval, so that
| > my program can check for some kind of user input to abort run-away scripts.
|
| You could use the mechanisms intended for the debugger, which give you
| control at each executed line, but this slows things down quite a bit.
| You can also use this to get control only once per function call, but
| that means a simple infinite loop can't be caught. If you hide the
| signal module from your users, you could use it yourself to set an
| alarm timer which executes every second or so. If you have threads,
| you could have another thread keep an eye open as per
| sys.check_interval.
Hmmm... okay, well it sounds like -something- can be done. :) When I get
to that point, I'll just have to decide on what the best option is. It
would be nice to allow the scripts to sit in a loop while the program still
managing the GUI, but without threading that probably is not a reasonable
thing to do. At any rate, the only thing that this is really needed is for
an emergency abort by the user.
Thanks, this has helped a lot.
----------------------------------------------------------------------------
Dianne Kyra Hackborn "The United States is in no sense founded upon
hackbod@mail.cs.orst.edu the Christian doctrine."
Oregon State University -- George Washington
//www.cs.orst.edu/~hackbod/