Question on multiple Python users in one application

[Michael Torrie]

On 10/06/2016 04:47 PM, Loren Wilton wrote:
> 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.

So I take it that currently users access the software running in the
virtual mainframe over telnet or some form of serial link and that they
interact with it in a text terminal?  This point is fairly important,
because if it's true, then you really don't have any in-band way of
clients talking to some Python process(es) running on the machine
hosting the virtual mainframe.

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

It's a start.  This is fairly interesting. I love the welding of old and
new technologies in innovative ways.  Please continue.

> 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.

You'll just have to implement Python support for these frames of
reference. Python is not going to be running on the virtual hardware;
it's running on Windows.  All you need to do is provide a way for the
remote end users to talk to the Python server running on the windows
machine would define sessions for the users and manage the interaction
with the virtual mainframe.  No matter how you cut it, Python is
separate from the users and separate from the mainframe since you can't
run Python on the mainframe itself.  The only thing that makes sense is
to develop some kind of Python-based server architecture that clients
can talk to to do things via Python on behalf of the user.

At least that's the way I see it pending an answer to the question of
how users interact with this mainframe and its programs.