Andrew McNabb <[EMAIL PROTECTED]> 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/ ----------------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
