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

[Andrew Svetlov]

Guido, from my perspective asyncio is just great.
Because:

1. It raised striving for better coroutine based solutions like curio. We
could borrow best ideas and incorporate them into asyncio. I don't want to
rush, don't get me wrong please. Maybe some third-party library built on
top of asyncio but designed with curio spirit for proving the concept.
BTW Curio was born after async/await syntax which was in turn born by real
asyncio use cases.

2. asyncio was designed as the grand basement standard for asynchronous
development.
It *right now* is supported by Tornado and Twisted. The best practice for
tornado users (if they has been ported their codebase to Python 3) is using
asyncio compatible libraries for communicating with databases etc AFAIC.
I'm considering this as very big win for both asyncio and tornado/twisted.
But this way is possible only because asyncio supports futures, callbacks,
protocols as low-level API.

On Mon, Nov 7, 2016 at 9:58 PM 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.
>
> 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)
> _______________________________________________
> 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/

-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20161107/d7c683ee/attachment.html>