On 04 Oct 2016, at 07:26, Chris Angelico
wrote: On Tue, Oct 4, 2016 at 4:25 PM, Rene Nejsum
wrote: On 04 Oct 2016, at 02:09, Stephen J. Turnbull
wrote: Rene Nejsum writes:
I believe that you should be able to code concurrent code, without being to explicit about it, but let the runtime handle low-level timing, as long as you know your code will execute in the intended order.
Isn't "concurrent code whose order of execution you know" an oxymoron?
You are right, I should have been more specific. What I ment was that I don’t need code filled with async/await, I don’t care where it blocks, as long as it (the specific code block iI am looking at) runs in the order i wrote it :-)
Then you want threads. Easy!
Well, yes and no. I other languages (Java/C#) where I have implemented concurrent objects ala PYWORKS it works pretty well, as long as you have less than maybe 10.000 threads But, in Python (CPython2 on multicore CPU) threads does not work! The GIL makes it impossible to have for example 100 threads sending messages between each other (See the Ring example in PYWORKS), that’s one reason why it would be interesting to have some kind of concurrency support built into the Python runtime. Today I see all kinds of tricks and workarounds to get around the GIL. Raging from starting several Python interpreters to difficult to read code using yield (now async/await), but when you have seen much more elegant support (Go, Erlang, maybe even ABCL) you kind of wish this could be added to you own favourite language. br /Rene
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/