On Mon, Nov 7, 2016 at 4:18 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Nov 7, 2016, at 11:58 AM, Guido van Rossum <guido@python.org> wrote:
I would caution against rushing into anything rash here. Nathaniel's post will stand as one of the most influential posts (about async I/O in Python) of this generation, and curio is a beacon of clarity compared to asyncio. However, asyncio has a much bigger responsibility at this point, as it's in the stdlib, and it must continue to support its existing APIs, on all supported platforms, whether we like them or not.
My smiley may have been insufficiently forceful. I was not intending to seriously suggest a departure from the current API. A 3.7/3.8 refinement into preferring a 'current_event_loop' coroutine might be a nice future direction but it is not something that should happen lightly.
It wasn't aimed at you, it was aimed at asyncio's staunchest supporter/maintainers. (Including myself. :-)
I would love to see a design for a new API that focuses more on coroutines. But it should be a new PEP aimed at Python 3.7 or 3.8.
I am tempted to start defending asyncio, but I'll resist, because nothing good can come from that.
TBH I think that this discussion stems from a *strength* of asyncio's design, not a weakness. As David did, let me underscore Brett's comment: the fact that asyncio has multiple, separable layers which each interact via well-defined interfaces has allowed for a tremendous amount of experimentation and refinement. Most languages with async features are locked into a particular substrate, and languages without async features end up being an uncoordinated mess of incompatible APIs. I feel like we're really getting the best of both worlds: language-level support with interoperability and ecosystem considerations baked in right from the start.
The potential for growth and improvement necessarily comes along with disagreement and criticism but it seems like overall this is a very healthy development.
Right now we're talking about this at the async event layer, but previous work at the loop layer (uvloop) also points in exciting future directions for community improvements that maintain interoperability across the whole ecosystem. All the integration points exposed in asyncio's design already seem to be benefiting from community-wide scrutiny and tinkering.
I think Nathaniel expressed his appreciation for this as well (especially in his acknowledgments section). In terns of Python's historic development, I think it's fascinating that this can still be seen as a development building on Python's approach to iteration: In Python 0.0 all we had was `for x in <list or tuple>` (I believe even then, it was possible to write extension types in C that also supported iteration, but I'm not sure). We then expanded upon this to add `__iter__` and `__next__` (néé `next`), then yield, then send() and throw(), then `yield from` (I still regret we didn't manage to get this into 2.7 due to some stupid process issue), then the asyncio library, then async/await, and it seems this (degenerate :-) tree will still bear more fruit in the future. (And I may even have missed a PEP or two.) Just imagine the alternate universe where Python 0.0 had borrowed its for-loop from C instead of from ABC! Which means the seed of all this goes back over 35 years. I hope Lambert Meertens and Leo Geurts are proud. -- --Guido van Rossum (python.org/~guido)