[Python-Dev] Addition of "pyprocessing" module to standard lib.

[Charles Cazabon]

Andrew McNabb <amcnabb at mcnabbs.org> wrote:
> 
> Think of the processing module as an alternative to the threading
> module, not as an alternative to MPI.  In Python, multi-threading can be
> extremely slow.  The processing module gives you a way to convert from
> using multiple threads to using multiple processes.

Indeed; pyprocessing was exactly what I wanted, and worked exactly as it said
it did.  It had essentially no learning curve at all because of its
implementation of essentially the same interface as the threading module.
It's remoting capabilities are almost surplus to requirements; if I wanted
that, I might use MPI or something else.

> If it made people feel better, maybe it should be called threading2
> instead of multiprocessing.  The word "processing" seems to make people
> think of parallel processing and clusters, which is missing the point.

"threading" is to threads as "processing" is to processes; that's why it was
named processing.  But the choice of name shouldn't affect the decision as to
whether it should be included or not.

> Anyway, I would love to see the processing module included in the
> standard library.

I would as well; I'm using it in a current project, and can see opportunities
for it to be useful in other projects.  My only note is that based on my
experience, the code needs a little cleanup for portability reasons before it
is included with the Python standard library -- it worked fine as-is on Linux,
but needed some hackery to get running on a slightly elderly Solaris 8 box.  I
didn't test it on anything else.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------