I still don't understand why this has to be in the same process space as the VM. Wouldn't it be a lot simpler to create a simple RPC layer (all localhost of course) to interface between the VM and a Python server that spins up multiple processes or sessions? Kind of like how Python for a web server would work. If a request comes in-band from the client to the VM that necessitates handing off to Python, the RPC layer would do this.
Assuming that all Python usages are single procedure calls, then all of the parameters can be marshalled and passed to another process. I suppose it may or may not be possible to modify the internals of structured parameters (arrays, lists, dictionaries, etc) and return the modified values, depending on how marshalling works. And it may or may not be fast.
If the Python code wants to make reverse calls back into the VM environment (and it may well want to do this, for instance for database access) then it is still possible but starts to get trickier, and again possibly slower.
Depending on use cases, any marshalling slowness might not matter at all. Or it might matter a great deal. Unfortunately I don't yet have any clearly defined use cases from the people that should be thinking about that. So at the moment I'm trying to follow the original concept spec as closely as possible, which is "integrate Python in the VM environment."
Loren
-- https://mail.python.org/mailman/listinfo/python-list
