Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not wrong. If running two processes counts as parallelism, then everything does parallelism, and it becomes pointless to talk about it.


Then one should talk about how convenient the related abstractions are. I like the concurrent.futures library.


Concurrency is not the same as parallelism. Python has good concurrency support, I agree. Python (C Python) does not support parallelism however due to its Big Interpreter Lock which actively prevents any parallelism in Python code.

This was probably a conscious design decision on the part of C Python implementers and perhaps a good one. But we should not claim that Python is something which (actively and by design) it's not.


I use `concurrent.futures.ProcessPoolExecutor` fairly often. I handle inter-process communication usually through a database or message queue, expecting that someday I'll want to go clustered instead of just single-machine multiprocessing. I've been burned by implementing multithreading and then needing to overhaul to clustered enough times to stop doing it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: