Question on multiple Python users in one application

[Loren Wilton]

>> the multi-user program is a virtual machine
>> implementation
>> and the programs running on the machine have resources
>> like variables, arrays, files, and databases
>
> Python variables? Python arrays (lists? tuples?)? Or some other sort of 
> "variables" and "arrays" that exist outside of Python?
>
> You _really_ need to describe your execution environment ;)

http://bitsavers.informatik.uni-stuttgart.de/pdf/burroughs/B6500_6700/1035441_B6500_B7500_Stack_Mechanism_1968.pdf

The linked paper By Erv Hauck and Ben Dent describes what our ancestor 
machine looked like in 1968, and is about the most recent documentation 
commonly available on the web. Its been a few years since then, and the 
machine has changed a little over time, but the basics of the word format 
and stack mechanism and program structure are basically unchanged.

Since the machine is no longer represented by hardware, but instead by an 
emulator running on Windows, we have some additional capabilities. For 
instance, instead of writing a Python interpreter that will run inside the 
virtual machine structure (effectively being a normal B6500 program, in 
terms of the referenced document) I can use a Python interpreter (CPython) 
that is an existing DLL running in the WIndows environment, and do a 
procedure call from my B6500 environment into the Python environment.

Effectively this is a call from one stack-based procedure using one bytecode 
to another stack-based procedure using a different bytecode. The interpreter 
for the B6500 bytecode will realize what it is calling, fabricate an 
appropriate call into CPython (possibly switching to a different thread if 
that is necessary) and then let the Python code do its thing. Eventually the 
procedure call will (probably) return, and the B6500 code will resume 
execution. Basically there is a fence where we swich between interpreters on 
a procedure call or return boundary.

The Python code is running as (I hope) a native Windows DLL, so should be 
able to access any existing Python libraries that exist on the WIndows 
machine. Obviously this Python code will be using Windows-shaped data 
objects like integers, floats, and strings.

The B6500 code also has integers, floats, doubles, and strings, but they all 
look different from what Windows data looks like. Since Python accesses 
things as objects and objects have accessor methods, I am reasonably sure I 
can either subclass existing Python objects to access B6500 data, or simply 
make new objects to access that data. Thus the Python code, even though it 
is running in its own interpreter, will be able to access resources within 
the virtual machine environment.

Does that help? I can expound more if needed, but I don't want to bloat the 
newsgroup with irrelevent stuff.

I don't think my main concern here is being able to call the CPython 
interpreter routines, but instead it is to be able to provide separate 
sandboxes for the various programs ("stacks", in B6500 terminology) that 
might have their own Python sessions or programs.

One possible scenario is a B6500 user, sitting at a terminal, and typing 
"run python". That should get him a copyright notice and a >>> prompt, and 
he should be able to carry on just as though he was sitting at a Windows 
command line. The guy at the terminal in the next office should be able to 
be doing the same thing at the same time.

        Loren