Josiah Carlson wrote:
> I do, however, doubt that free threading approaches will be the future
> for concurrent programming in CPython.
Hear, hear! IMO, it's the combination of the GIL with a compiler which never
decides to change the code execution order under the covers that makes
threading *not* a pain in Python (so long as one remembers to release the GIL
around blocking calls to external libraries, and to use threading.Queue to get
info between threads wherever possible).
The desire to change that seems to be a classic case of wanting to write
C/C++/Java/whatever in Python, rather than writing Python in Python.
And thanks to Bruce for starting the recent multi-processing discussion -
hopefully one day we will have mechanisms in the standard library that scale
relatively smoothly from PEP 342 based logical threads, through
threading.Thread based physical threads, to <something> based subprocesses.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
