Python to Python communication

[Harald Massa]

Hello,

I have a group of Python programms which I want to teach to "talk to each
other".

All run on Windows, on the same computer or in the same intranet.
Security of communication is not an issue (encryption on lower level
protocols / intra computer communication). Partially these programs are
using wxPython.

It is important that the communcation is "only an added feature", I am
not willing to spend big memory / computing ressources on it.
So I googled and came up with at least the following opportunities:

XMLRPC - quite "simple" to implement within python, contained in my
favourite web framework Quixote / medusa

SOAP - around the same amount of work as XMLRPC

----> these two are fully buzzword compatible to enterprise communication
needs. But are they really lightwight and needed?
Banana - within the twisted framework. Is described as high performance
with very litte ressources. From my scanning of twisted it is meanwhile
possible to integrate it within wxPython and you only need to sell the
soul of your firstborn for it; but I got the impression twisted rather
needs a total commitment than a "I just need some banana, man"

pyro - Python Remote Objects. Irmen de Jong has a "get Firefox" icon on
it's page and he plays with the name "pyro", which makes a good
impression. It looks rather "ripe", but: he is talking about "pyro 4.0"
which will be incompatible with pyro 3.4 and a total redesign. That makes
me shudder.

COM / DCOM. From our favourite software company, available mainly within
windows. Wrapped excellently with pywin32 ... but needs some seriuos
type-mangeling to get through and around 2 Gig of Browser Cache to read
all the MSDN documentation, which is quite C-ish.

socket / select. Within the standard lib. Does not look to hard to get to
work, working samples included in the nutshell.

----

so, I am stranded ... and ask C.L.P. for recommendations .

What library have you used and would recommend?

Harald

[Diez B. Roggisch]

hi,

XMLRPC - quite "simple" to implement within python, contained in my
favourite web framework Quixote / medusa

SOAP - around the same amount of work as XMLRPC

----> these two are fully buzzword compatible to enterprise communication
needs. But are they really lightwight and needed?
Unless you don't need the connectivity to other non-python apps that depend
on using one of them, stay clear of those two. They are pretty slow,
primitive in the sense that all they give you is a stateless C-api-like
calls and by far not as mature as say corba. And last time I checked, the
SOAP-support in python was far from beeing complete. And that checking of
mine hasn't been too long ago.

Banana - within the twisted framework. Is described as high performance
with very litte ressources. From my scanning of twisted it is meanwhile
possible to integrate it within wxPython and you only need to sell the
soul of your firstborn for it; but I got the impression twisted rather
needs a total commitment than a "I just need some banana, man"
pyro - Python Remote Objects. Irmen de Jong has a "get Firefox" icon on
it's page and he plays with the name "pyro", which makes a good
impression. It looks rather "ripe", but: he is talking about "pyro 4.0"
which will be incompatible with pyro 3.4 and a total redesign. That makes
me shudder.
Don't used those two, but if I had a similar situation to yours (namely no
non-python-apps), I'd certainly give pyro a try.
COM / DCOM. From our favourite software company, available mainly within
windows. Wrapped excellently with pywin32 ... but needs some seriuos
type-mangeling to get through and around 2 Gig of Browser Cache to read
all the MSDN documentation, which is quite C-ish.
I use Linux, so I won't comment on that.
socket / select. Within the standard lib. Does not look to hard to get to
work, working samples included in the nutshell.

Been down that road - but while its quick to start, it nearly as fast gets
tedious as your requirements develop - usually, you end up with your own
xmlrpc-style implementation. Better skip that.

I personally have very good expiriences with corba - omniORBpy, to be
precise. Don't know how well that runs on windows, though. But on *nix, it
certainly saved my day more than once.

Regards,

Diez

[Martin Franklin]

On Mon, 11 Oct 2004 12:40:07 +0000 (UTC), Harald Massa
<cp*********@sp amgourmet.com> wrote:

Hello,

I have a group of Python programms which I want to teach to "talk to each
other".

All run on Windows, on the same computer or in the same intranet.
Security of communication is not an issue (encryption on lower level
protocols / intra computer communication). Partially these programs are
using wxPython.

It is important that the communcation is "only an added feature", I am
not willing to spend big memory / computing ressources on it.

[SNIP]

pyro - Python Remote Objects. Irmen de Jong has a "get Firefox" icon on
it's page and he plays with the name "pyro", which makes a good
impression. It looks rather "ripe", but: he is talking about "pyro 4.0"
which will be incompatible with pyro 3.4 and a total redesign. That makes
me shudder.

[SNIP]
Harald

Harald,

I only have experience with Pyro, so am biased, but from your rather
sketchy
description I think it would have the smallest impact (in terms of existing
code re-work) as it can simply be bolted on with the inclusion of a couple
of extra classes. At least that was my experience when I needed to get a
couple
of python applications talking...

Just my tupence worth :-)

Martin

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Thomas Guettler]

Am Mon, 11 Oct 2004 12:40:07 +0000 schrieb Harald Massa:

Hello,

I have a group of Python programms which I want to teach to "talk to each
other".

All run on Windows, on the same computer or in the same intranet.
Security of communication is not an issue (encryption on lower level
protocols / intra computer communication). Partially these programs are
using wxPython.

Hi,

Before choosing a framework (pyro, socket or other) you should know
how you want to communicate.

The easiest is "client-server". There is one server and several
clients connect to it.

Peer to peer: There is no central server. All can talk to each other.
The problem is: How to find the other? If there are on one computer
this is easy: Just write files to a directory all processes know.
But if you want to talk to other computers, you need to know their
IP addresses.

For the communication UDP, TCP or HTTP can be used. I would not
use HTTP (XMLRPC or SOAP) if you don't need to. UDP is stateless,
and can be used for broadcasts.

I would use pyro or the socket module.

HTH,
Thomas

[Istvan Albert]

Harald Massa wrote:

I have a group of Python programs which I want
to teach to "talk to each other". What library have you used and would recommend?

I think this depends on what exactly the nature of
the "communication" .Do you want to send data across or
functionality.

XMLRPC and pyro are about sharing behavior:
functions or methods.

If you need to keep a connection open and keep
exchanging raw data, then sockets might make more sense.

Istvan.

[Alan Kennedy]

[Harald Massa]

I have a group of Python programms which I want to teach to "talk to each
other".

[Thomas Guettler] Peer to peer: There is no central server. All can talk to each other.
The problem is: How to find the other? If there are on one computer
this is easy: Just write files to a directory all processes know.
But if you want to talk to other computers, you need to know their
IP addresses.

Or use a peer-to-peer library that has solved all of those problems already

http://www.python.org/other/spread/

regards,

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan

[Irmen de Jong]

Harald Massa wrote:

pyro - Python Remote Objects. Irmen de Jong has a "get Firefox" icon on
it's page and he plays with the name "pyro", which makes a good
impression.
Hey, thanks :)
It looks rather "ripe", but: he is talking about "pyro 4.0"
which will be incompatible with pyro 3.4 and a total redesign. That makes
me shudder.

Pyro is "ripe"... version 3.0 was released Q4, 2002, so the 3.x
versions have been around and in active use for 2 years now.

I've been talking about Pyro 4.0 for a long time, but we haven't
even begun the real design of it. Partly because of lack of time,
partly because Pyro 3.x does its job so well (not my own words).

What is it that makes you shudder?
If you don't want to switch to Pyro 4.0 once (if??) it is released,
just continue using Pyro 3.x. I have no intentions of abandoning
the 3.x version: if there is an itch, or a bug, it will be addressed.
Regards,

Irmen de Jong

[aurora]

A cheap solution for brainstorming: just output messages to files.

p1/001.msg
p2/002.msg
...etc...

Do some polling to pick up messages. This is very asynchronize and maybe
useful for some communication pattern.

[Harald Massa]

Hello Irmen,

Pyro is "ripe"... version 3.0 was released Q4, 2002, so the 3.x
versions have been around and in active use for 2 years now.
That is really good information! Thank you. "active for 2 years" is
rather "mature" then only "ripe" :)))
I've been talking about Pyro 4.0 for a long time, but we haven't
even begun the real design of it.
What is it that makes you shudder?

Really exactly that :))) I do not know you at all; as I said: your
presentation, the documentation and the voices within c.l.p. give me a
very positive feeling towards you and your software. So all my
"shuddering " comes from this bits of information: "the author of a
product thinks to further develop it a complete redesign - not a gradual
upgrade - is necessary - so maybe I should wait for that" :)) And the
fear, that new ideas will be postponed to the imaginary future version.
(I tend do to such things with my own projects, too )

So I will give a very deep look at PyRo and spread... especially because
I need that "peer to peer"

Thank you all for your support!

Harald

[Harald Massa]

Alan Kennedy <al****@hotmail .com> wrote in

[Thomas Guettler]

Peer to peer: There is no central server. All can talk to each other.
The problem is: How to find the other? If there are on one computer

Yes, considering my challenge "peer to peer" would fit best
Or use a peer-to-peer library that has solved all of those problems
already

http://www.python.org/other/spread/

Yeah, spread looks beautifull from it's documentation. But I failed in
setting up ... the python-module is prepared for spread 3.16.4, actual is
3.17.2, which has total different librarynames to start with ... so

python setup.py build --compiler=mingw3 2 fails badly when trying to link.

Has someone succeeded in doing a windows build for python 2.3.4 and spread
3.17.2 ??? I would be very thankfull for a howto or a spread.pyd :)

Harald