[Python-ideas] async objects

[Yury Selivanov]

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