[Python-Dev] async/await behavior on multiple calls

[Paul Sokolovsky]

Hello,

On Tue, 15 Dec 2015 17:29:26 -0800
Roy Williams <rwilliams at lyft.com> wrote:

> @Kevin correct, that's the point I'd like to discuss.  Most other
> mainstream languages that implements async/await expose the
> programming model with Tasks/Futures/Promises as opposed to
> coroutines  PEP 492 states 'Objects with __await__ method are called
> Future-like objects in the rest of this PEP.' but their behavior
> differs from that of Futures in this core way.  Given that most other
> languages have standardized around async returning a Future as
> opposed to a coroutine I think it's worth exploring why Python
> differs.

Sorry, but what makes you think that it's worth exploring why Python
Python differs, and not why other languages differ? For example,
JavaScript has hard heritage of callback mess. To address that at least
somehow, Promises where introduced, which is still too low-level
concurrency mechanism. When they finally picked up coroutines, they
still have to be carry all that burden of callback mess and
Promises, and that's why "ES7" differs.

Also, what "most other languages" do you mean? Lua was a pioneer of
coroutine usage in scripting languages, with research behind that.
It doesn't have any "futures" or "promises" as part of the language.
It has only coroutines. For niche cases when "futures" or "promises"
needed, they can be implemented on top of coroutines.

And that's actually the problem with Python's asyncio - it tries to
marry all the orthogonal concurrency concepts, unfortunately good
deal o'mess ensues. It doesn't help on "PR" side too, because coroutine
lovers blame it for not being based entirely on language's native
coroutines, strangers from other languages want to twist it to be based
entirely on foreign concepts like futures, Twisted haters hate that it
has too much complication taken from Twisted, etc.

> 
> There's a lot of benefits to making the programming model coroutines
> without a doubt.  It's absolutely brilliant that I can just call code
> annotated with @asyncio.coroutine and have it just work.  Code using
> the old @asyncio.coroutine/yield from syntax should absolutely stay
> the same. Similarly, since ES7 async/await is backed by Promises
> it'll just work for any existing code out there using Promises.
> 
> My proposal would be to automatically wrap the return value from an
> `async` function or any object implementing `__await__` in a future
> with `asyncio.ensure_future()`.  This would allow async/await code to
> behave in a similar manner to other languages implementing
> async/await and would remain compatible with existing code using
> asyncio.
> 
> What's your thoughts?

My thought is "what other languages told when you approached them with
the proposal to behave like Python?".

Also, wrapping objects in other objects is expensive. Especially if
the latter kind of objects isn't really needed - it's perfectly
possibly to write applications which don't use or need any futures at
all, using just coroutines. Moreover, some people argue that most apps
real people would write are such, and Futures are niche feature, so
can't be center of the world.

> 
> Thanks,
> Roy
> 

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com