You forgot about Cython [http://cython.org/]. It somehow connected to PyRex and seems to be mice to use.
amund
· 12 months ago
Thanks, wasn't aware of Cython, will have a look. (The one I most recently tested was cinpy)
George
· 12 months ago
Hi. Maybe, you should also add Twisted and rpyc...
amund
· 12 months ago
thanks George, have added those now.
Jacinto
· 12 months ago
There is also Boost.Python which provides interoperability between Python and C++.
amund
· 12 months ago
Thanks Jacinto, added now.
Ian Ozsvald
· 12 months ago
I've recently written a long article on using ShedSkin to give my Python neural-network code a 196* speed increase. Several contributors took the code and made Cython, Numpy and raw-C variants alongside my Vanilla Python and Psyco timings to offer their own comparisons. The numbers are very useful if you're looking into these frameworks: http://ianozsvald.com/2008/11/17/making-python-... Ian.
amund
· 12 months ago
Thanks Ian, added a benchmark link next to ShedSkin
lorg
· 12 months ago
You should add the multiprocessing module as well. (PyProcessing before it was included in the standard library.) When seeking to take advantage of multiple cores, it performs well enough.
Ben Cummings
· 12 months ago
Putting Stackless Python and threads in the same breath seems pretty misleading to me, and I would think long and hard before using either approach. Rewrite your code with threads, and you need to make sure at least one of your threads will be spending enough time in C code that releases the GIL to actually give the other thread time to run concurrently, or else you've just wasted a lot of time and introduced a whole lot of concurrency bugs to write a program that still only runs on one core most of the time, thanks to the aforementioned GIL.
Stackless Python gives you logical parallelism, but it doesn't really give you distribution. You may have 100,000 tasklets running, but you're still only using one core of your one processor until you use one of the other approaches to actually parallelize your program. Stackless will allow you to then pickle your tasklets and swap them between processes or machines, but you've just tossed a lot of the nice, deterministic nature of Stackless tasklets out the window.
It also bears mentioning that RPython isn't really specified and isn't intended for use outside of PyPy, meaning it might change out from underneath you if you try to build anything on top of it, and it apparently has some pretty awful error handling (are you alright with your Python program segfaulting?) I'd love for them to standardize it and be willing to make RPython a language for general use, but they aren't willing to do that yet.
Ashish
· 11 months ago
Excellent list. Can you post similar tools for Google App Engine too.
All Comments
The numbers are very useful if you're looking into these frameworks:
http://ianozsvald.com/2008/11/17/making-python-...
Ian.
When seeking to take advantage of multiple cores, it performs well enough.
Stackless Python gives you logical parallelism, but it doesn't really give you distribution. You may have 100,000 tasklets running, but you're still only using one core of your one processor until you use one of the other approaches to actually parallelize your program. Stackless will allow you to then pickle your tasklets and swap them between processes or machines, but you've just tossed a lot of the nice, deterministic nature of Stackless tasklets out the window.
It also bears mentioning that RPython isn't really specified and isn't intended for use outside of PyPy, meaning it might change out from underneath you if you try to build anything on top of it, and it apparently has some pretty awful error handling (are you alright with your Python program segfaulting?) I'd love for them to standardize it and be willing to make RPython a language for general use, but they aren't willing to do that yet.