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

Guido van Rossum guido at python.org
Mon Nov 7 14:58:27 EST 2016


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.

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.

On Mon, Nov 7, 2016 at 11:41 AM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Nov 7, 2016, at 11:08 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
>
> [..]
>
> Sorry, this was a bit tongue in cheek.  This was something I said to Guido
> at the *very* beginning of Tulip development, when asked about mistakes
> Twisted has made: "don't have a global event loop, you'll never get away
> from it".
>
> I still think getting rid of a global loop would always be an improvement,
> although I suspect it's too late at this point.  `await
> current_event_loop()` might make more sense in Asyncio as that's not really
> "global", similar to Curio's trap of the same design; however, I assume
> that this was an intentional design disagreement for a reason and I don't
> see that reason as having changed (as Yury indicates).
>
>
> The latest update of get_event_loop is a step in the right direction. At
> least now we can document the best practices:
>
> 1. Have one “main” coroutine to bootstrap/run your program;
>
> 2. Don’t design APIs that accept the loop parameter; instead design
> coroutine-first APIs and use get_event_loop in your library if you
> absolutely need the loop.
>
> 3. I want to add “asyncio.main(coro)” function, which would create the
> loop, run the “coro” coroutine, and correctly clean everything up.
>
> What you propose, IIUC is a step further:
>
> * Deprecate get_event_loop();
>
> * Add “current_event_loop()” coroutine.
>
> This will enforce (1) and (2), making asyncio library devs/users to focus
> more on coroutines and async/await.
>
> Am I understanding this all correctly?
>
>
> Yep.  It's not so much making users focus *more* on coroutines, as having
> a way to pass a loop to a coroutine that is explicit (the coro needs to be
> scheduled on a loop already, so the binding has been explicitly specified)
> but unobtrusive.
>
> -glyph
>
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161107/f3399171/attachment-0001.html>


More information about the Async-sig mailing list