[Async-sig] Some thoughts on asynchronous API design in a post-async/await world

[Guido van Rossum]

On Mon, Nov 7, 2016 at 4:18 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Nov 7, 2016, at 11:58 AM, Guido van Rossum <guido at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161107/cc08482c/attachment.html>