[Python-Dev] API design: where to add async variants of existing stdlib APIs?

[Nick Coghlan]

On 2 March 2017 at 02:29, Barry Warsaw <barry at python.org> wrote:

> On Mar 01, 2017, at 10:55 AM, Victor Stinner wrote:
>
> >I suggest to create 3rd party modules on PyPI. It became easy to pull
> >dependencies using pip and virtualenv.
> >
> >It seems like https://github.com/aio-libs is the home of many asyncio
> >libraries.
>
> This is what we did for aiosmtpd, an asyncio-based replacement for smtpd.
> It's worked out great on all fronts so far (good community contributions,
> rapid development, API flexibility as we move toward 1.0, good visibility
> inside the more general aio-libs umbrella).
>

While I agree with this approach for higher level stuff, it's specifically
the lower level pieces that just interact with the async/await language
features rather than the event loop itself where I needed some discussion
to clarify my own thoughts :)

My conclusion from the thread is:

- if it needs to depend on asyncio, it should either go in asyncio, or be
published as a third party aio-lib
- if it *doesn't* need to depend on asyncio, then it's a candidate for
stdlib inclusion (e.g. the coroutine support in inspect)
- both asynccontextmanager and AsyncExitStack actually fall into the latter
category
- other contextlib APIs like closing() should be able to transparently
support both the sync and async variants of the CM protocol without
negatively affecting the synchronous version
- so for the specific case of contextlib, supporting both synchronous and
asynchronous contexts in the one module makes sense
- I still plan to keep the test cases separate, since the async test cases
need more infrastructure than the synchronous ones

What we shouldn't do is take this design decision as setting a binding
precedent for any other modules like itertools - the trade-offs there are
going to be different, and there are already third party modules like
https://github.com/asyncdef/aitertools that provide equivalent APIs for the
asynchronous programming model.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170302/eac49c50/attachment.html>