Hello, On Tue, 15 Dec 2015 17:29:26 -0800 Roy Williams <rwilli...@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:pmis...@gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
