On Mon, Nov 7, 2016 at 4:18 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> > On Nov 7, 2016, at 11:58 AM, Guido van Rossum <gu...@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)
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
