5 ms·
Speed, definitely. Although in defence Ive always found python very easy to "hack". Writing a C extension to do computationally intensive work is fairly simple
by ErrantX 14y ago
Speed, definitely. Although in defence Ive always found python very easy to "hack".
Writing a C extension to do computationally intensive work is fairly simple.
With its versatility and extensability I once threw together a proof of concept password cracking cluster in a week. Redis for queues/data, MySQL for data, hashing code in a C extension, flask for the web interface. Cross platform and lovely :-)
Threading is the only real let down for me.
- masklinn 14y ago> Writing a C extension to do computationally intensive work is fairly simple. Even more so with Cython, which does most of the hard work for you.
- Xixi 14y agoOr the recent numba: https://github.com/numba/numba https://github.com/numba/numba
- njharman 14y agoThere's so many solutions to the "speed" argument I don't even see it as an issue. - C-extentions (many std and 3rd party libs that need speed are written in C) - numpy http://numpy.scipy.org/ - numba https://github.com/numba/numba - cython http://www.cython.org/ - pyrex http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ - http://psyco.sourceforge.net/ -> PyPy (some day...)
- SoftwareMaven 14y agoWhere you were already using external queues, threads shouldn't have been an issue: just have multiple processes going (one for each core). Or use the processing package if you want more "threadlike" control. It is unfortunate that you have to know that kind of thing a priori. "Oh, look, a nice, built-in threading module." Yes, BUT... EDIT: I just re-read the way you wrote the "threading" comment and realized you probably weren't talking about it in the same context. Amazing what a word or two can do to understanding.