Question on multiple Python users in one application

[Chris Angelico]

On Fri, Oct 7, 2016 at 9:09 AM, Loren Wilton <myspamacct at earthlink.net> wrote:
>> Okay. Before you go one micron further, answer this critical question:
>>
>> *Do you trust your users?*
>
>
> The basic answer is yes. This program amounts to a virtual machine
> implementation of a multi-processor and multi-user mainframe computer. It
> runs on a Windows box of its own. It has an IO subsystem of its own with a
> pretty hefty firewall machine in front of it before it gets to internet
> access. The Windows OS doesn't have network access at all. That may sound
> like a joke to you, but some of the biggest companies in the world have this
> machine running in their back rooms.

Good. And no, that's most definitely not a joke; having a VM with no
network access is a very smart way to manage security.

So you don't have to worry about someone deliberately trying to mess
you around. This saves a *TON* of trouble.

> The goal at the moment is to see if I can make it appear that I have Python
> running more or less natively on the virtual machine. This means that Python
> will have direct access to user variables, files, and direct database access
> for the mainframe databases. Since the mainframe data format doesn't match
> that of the commmon Python objects, I'll either have to subclass the Python
> objects or make my own objects similar to the equivalent Python objects for
> things like numbers and strings. That is a project for tomorrow, not today.
> It seems straight-forward, just a lot of work.

That's the inherent work of trying to make one thing talk to another.
Most likely, you can ignore most of the differences, and just make
sure your script writers are aware, for instance, that integer
wrap-around doesn't exist in Python. Unless someone's been
deliberately exploiting those kinds of features, that's unlikely to
cause problems.

>> You can avoid name collisions simply by giving each user a
>> module; one person's "spam" doesn't collide with another user's "spam"
>> any more than math.log collides with logging.log. However, this is
>> *not* protecting one user from another - it just protects against
>> accidents. (I could easily reach into someone else's module by typing
>> "fred.spam = 123".)
>
>
> This particular mainframe architecture is odd, by today's machine standards.
> It is a stack machine. The stack is not a simple linear stack as far as
> addressing is concerned, but more of a tree structure. All user programs
> have stacks that are rooted at D0 in the operating system, at D1 in their
> own code file, and at higher levels in various nested program procedures. A
> new process can be created by forking at any level, and the new process
> shares all data with the original program from that level outward. It is
> possible for one stack to export procedure entry points that can be called
> by other stacks. Variables, arrays, files, etc, can be passed fron one stack
> (process) to another stack (process).
>
>> So the question really becomes: How independent should the Pythons be?
>> Sharing data is far easier if they're less isolated, but then it's
>> harder to multithread.
>
>
> The desirable goal is to make it look like Python is a native language
> running on this machine, but also giving access to existing Python libraries
> running on the PC that contains this virtual machine. Effectively this is
> extending the boundaries of the virtual machine to include processor chips
> of a different architecture within the scope of the VM. This has security
> implications, but at the moment they are (at least partially) understood and
> accepted.

Hmmmmmm. Okay, so you have some pretty fundamental architectural
differences to deal with. I think what you're doing is going to be
possible, but either (a) this is a large and ongoing job, or (b)
Python won't feel truly native - it'll be a bridging system, and
people will need to understand both ends. Sounds like it'd be a good
fun project, though.

ChrisA