4 ms·
Another Python concurrent library?? To boot one which makes Python look like Java? This.that.that.this.whatever()? How is this better than a few simple lines o
by vegabook 11y ago
Another Python concurrent library?? To boot one which makes Python look like Java? This.that.that.this.whatever()?
How is this better than a few simple lines of multiprocessing module exactly?
Yes I'm being negative. People need to stop already adding yet more parallel libraries to Python. Contribute to existing 15+ options or stay away. Unless you're GvR (and even that's debatable) you're not helping the ecosystem - you're confusing it even further.
Python is not a good first choice for multicore anyway because it is at least 10x slower than compiled languages so the best you are hoping for is 8-core parallelism to get you back to the performance of single core C (or whatever compiled language you want). If you're serious about performance there is no other way than to abandon Python. Only Numpy (and Pandas) are keeping it competitive, and in a number of fields, it's looking more and more R-like as a prototyping-only language, with production in anything-but.
- deleted 11y ago[deleted]
- necrobrit 11y agoconcurrent.futures isn't really _another_ parallel library... its just the standard libraries higher level interface to both the multiprocessing and threading modules. See the PEP: https://www.python.org/dev/peps/pep-3148/ https://www.python.org/dev/peps/pep-3148/
- deleted 11y ago[deleted]
- DasIch 11y agoconcurrent.futures is not new, it has existed for years and is not an alternative to multiprocessing but an abstraction that can be used with threads and multiprocessing. The purpose is primarily to have a solution to promises/deferreds in the standard library.