On 2016-10-06 1:15 AM, Stephen J. Turnbull wrote:
These may be hard to explain, and I know you, Yury, and Guido are very
busy. But it's frustrating for all to see this go around in a circle:
"it's like it is because it has to be that way, so that's the way it is".
To add to what Nick said.
I myself would want to use a time machine to help design CPython runtime
to allow Golang style jof concurrency (although Golang has its own bag
of problems). Unfortunately there is no time machine, and implementing
that in CPython today would be an impossibly hard and long task.
To start, no matter how exactly you want to approach this, it would
require us to do a *complete rewrite* of CPython internals. This is so
complex that we wouldn't be able to even estimate how long it would take
us. This would be a far more significant change than Python 2->3. BTW
in the process of doing that, we would have to completely redesign the C
API, which would effectively kill the entire numpy/scipy ecosystem. If
someone disagrees with this, I invite them to go ahead and write a PEP
(please!)
On the other hand, async/await and non-blocking IO make it possible to
write highly concurrent network applications. Even languages with good
support of threading, such as C#, have async/await [sic!]. Even Rust
users want them, and will likely add them in the language or std lib.
Even C++ might have coroutines soon.
Why? Because Rust and C# can't "just" implement actors model. Because
threads are hard and deadlocks and code that is hard to reason about.
Because threads can't scale as good as non-blocking IO.
We probably could implement actors if we decided to merge Stackless or
use greenlets in the core. Anyone who looked at/debugged the
implementation of greenlets would say it's a bad idea. And gevent is
available for those who want to use them anyways.
In the end, async/await is the only *practical* solution for a language
like Python. Yes, it's a bit harder to design libraries that support
both synchronous and asynchronous APIs, but there's a way: separate your
protocol parsing from IO. When done properly, it's easier to write
unittests and it's a no-brainer to add support for different IO models.
Yury
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
