Python-IronPython-Jython Interpreters Interaction

There was a need to solve this problem: how to exchange data between different Python interpreters? I found several solutions, but I want to tell you about one, in my opinion, the most convenient one.

Choice of approach

To begin with, I tried to choose the most convenient solution from the set. It may not be correct to compare the message queue, sockets and RPC, but I proceeded from the task. Here is what is available:

TCP sockets

Using sockets, the easiest way to communicate, you can transfer any data, but the code will have to saturate with the implementation of its own protocol. This path is thorny, and mistakes are inevitable. Conclusion: suitable, but difficult.

ZeroMQ library

A very promising brokerless message queue. Implemented as a pyzmq and pyzmq-static library. For the first case, you need to install ZeroMQ itself - a shared library written in C. The second already contains a binary. It all started quite funny, the code worked fine until I switched to IronPython ...
For IronPython, pyzmq is not implemented, but not a problem, there is the .NET Integration, which allows the use of clrzmq - binding for .NET; and here the problems started. The binary is available through the VisualStudio plugin for nuget, so I had to compile the library. I downloaded the source, everything is convenient, the script is built with the build command, but not everything is so simple. Version 2 was not compiled at all, although the dependencies were resolved via nuget correctly (could a broken commit take?), 3 beta was compiled, but it even dropped by an example from the tutorial)
As a result, the network found the binary 2-ki, but it did not please me at all. Everything worked, but the API in 3-ke has changed so much that I didn’t want to rewrite the code a hundred times later. Conclusion: good, but raw outside pure python.
')

Pyro, set it on fire!

At first I decided to finish 0mq, but I remembered the existence of such a library as Pyro : libraries from the crisis of the 90s, which is doing well and developing. I will not list all its advantages, now only one interests - the interaction of interpreters. Immediately to the point, try an example from the tutorial , but with the difference that we run everything under different interpreters (I did not change the code, I just entered my nickname).

We start the name server under Jython, by the way, this is the first huge plus, the name server for 0mq has not been completed yet:

Wow! It was got ...

Now we register the server that will work under IronPython:

Registration completed successfully.

The next step is launching a client. We do it under the classical python (I immediately have a lot of them, but I ran the EPD):

Perfectly! It worked.

Pickle version

Alternatively, I tried to run one of the parts under Python 3. Without the hack it did not work: (The latter uses pickle of the third version + there are not some standard modules (removed, moved), although this behavior can be circumvented. But the main reason Pyro4 uses pickle to serialize , with the latest version. Here's how to get around this flaw and connect Python 3 to IronPython 2 and Jython 2:

import pickle pickle.HIGHEST_PROTOCOL = 2 

This should be added to the client code before importing Pyro. Everything worked:

Note the use of 64-bit Python 3 together with twos.

By the way, as an option, you can use the pyrolite library to directly connect from .NET or Java without the Python interpreter. This is actually a mini pickle.

In general, the solution with Pyro is still more pleasant than others, but if the system contains a lot of components of different versions, then it will probably be more profitable to use 0mq. Although I still dwell on Pyro4.