zproc

Updated readme to be a little better https://github.com/pycampers/zproc I use it in a couple of my own stuff which I have open sourced yet. I do plan to release them, and I hope I can prove the usefulness of the library using those... professional (corporate) stuff would be a far fetch for me, obviously.

Update - I hopefully made the language a little better? https://github.com/pycampers/zproc/blob/master/README.md

> "high performance" I never claimed it to be performant! "Above all, ZProc is written for safety and the ease of use." (Read here - https://github.com/pycampers/zproc?files=1#faq) > It's not a revolution I totally agree. It's just a better way of doing things zmq already perfected. Like, tell me if you've ever seen a python object that has a `dict` API, but does message passing in the background. > central (pubsub?) server. Central server, yes. It uses PUB-SUB for state watching and REQ-REP for everything else. > you've just "discovered" message-passing Guess you're right? 2 years is a peanut on the time scale... P.S. Thanks for all the feedback, I've been dying to hear something for a while now.

I believe that since the Advent of zeromq, parallelism is possible in almost any language, including python. My library lets you do parallelism in a unique way, where you do message passing parallelism without being explicit about it. https://github.com/pycampers/zproc/

> deal with serialization and communication I thought a lot about this problem, for over 2 years, and came up with zproc https://github.com/pycampers/zproc Basically, > It lets you do message passing parallelism without the effort of tedious wiring. You'll be doing message passing without ever dealing with sockets! Also, Shared memory parallelism is hard to get right irregardless of which language you use. I would recommend strongly against it, unless you're writing some really really really niche thing where message passing is a bottleneck (it isn't most of the time)