3

What is the best way to communicate between a Python 3.x and a Python 2.x program?

We're writing a web app whose front end servers will be written in Python 3 (CherryPy + uWSGI) primarily because it is unicode heavy app and Python 3.x has a cleaner support for unicode.

But we need to use systems like Redis and Boto (AWS client) which don't yet have Python 3 support.

Hence we need to create a system in which we can communicate between Python 3.x and 2.x programs.

What do you think is the best way to do this?

Marcelo Cantos
  • 181,030
  • 38
  • 327
  • 365
treecoder
  • 43,129
  • 22
  • 67
  • 91
  • Not constructive? These are often exactly the sort of questions we need answers to. Here is an excellent post that hasn't been over policed: https://stackoverflow.com/questions/43334302/communication-between-two-separate-python-engines – Lee Melbourne Nov 22 '18 at 10:15

1 Answers1

2

The best way? Write everything in Python 2.x. It's a simple question: can I do everything in Python 2.x? Yes! Can I do everything in Python 3.x? No. What's your problem then?

But if you really, really have to use two different Python versions ( why not two different languages for example? ) then you will probably have to create two different servers ( which will be clients at the same time ) which will communicate via TCP/UDP or whatever protocol you want. This might actually be quite handy if you think about scaling the application in the future. Although let me warn you: it won't be easy at all.

freakish
  • 54,167
  • 9
  • 132
  • 169
  • Yes, I am thinking exactly on these lines. But what's the communication medium I should use? MessagePack? or something else? – treecoder Sep 26 '12 at 10:32
  • Why won't it be easy? Designing a small rpc protocol in xml can be done in under 100 loc as long as you don't have special requirements... – l4mpi Sep 26 '12 at 10:32
  • @l4mpi Yeah, designing might be easy. However there are a lot of subtleties like making it fault tolerant, queueing requests/responses, caching ( if needed ), etc. etc. I'm not saying that it is extremely difficult, it's just that you need to be aware of such things and be more careful than usual. – freakish Sep 26 '12 at 10:39
  • @good_computer It depends on your situation. Most of the time I would go for JSON to be honest. MessagePack looks good, though ( didn't know it before ). – freakish Sep 26 '12 at 10:41
  • 1
    How about JSON and HTTP? Very easy to use protocol. – Lennart Regebro Sep 26 '12 at 20:56
  • @LennartRegebro There are some disadvantages of HTTP: you have to recreate request every time you want data but opening and closing HTTP connections eats resources and also you pass some additional ( and unnecessary ) data on each request/response ( for example headers ). So I don't think it suitable for this kind of task. As I said: I would use JSON with UDP or TCP. UDP is faster, but less reliable, so it actually depends what kind of data OP is dealing with and how important it is. – freakish Sep 26 '12 at 21:57
  • Ah, yes, in the comments you wrote JSON, I didn't see that. JSON + TCP works if he needs to do a lot of small transfers, sure. Going from TCP to UDP because of efficiency is almost always a mistake. – Lennart Regebro Sep 27 '12 at 05:20