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

[Nick Coghlan]

Short version:

- there are some reasonable requests for async variants of contextlib APIs
for 3.7
- prompted by Raymond, I'm thinking it actually makes more sense to add
these in a new `asyncio.contextlib` module than it does to add them
directly to the existing module
- would anyone object strongly to my asking authors of the affected PRs to
take their changes in that direction?

Longer version:

There are a couple of open issues requesting async variants of some
contextlib APIs (asynccontextmanager and AsyncExitStack). I'm inclined to
accept both of them, but Raymond raised a good question regarding our
general design philosophy for these kinds of additions: would it make more
sense to put these in an "asyncio.contextlib" module than it would to add
them directly to contextlib itself?

The main advantage I see to the idea is that if someone proposed adding an
"asyncio" dependency to contextlib, I'd say no. For the existing
asynccontextmanager PR, I even said no to adding that dependency to the
standard contextlib test suite, and instead asked that the new tests be
moved out to a separate file, so the existing tests could continue to run
even if asyncio was unavailable for some reason.

While rejecting the idea of an asyncio dependency isn't a problem for
asyncontextmanager specifically (it's low level enough for it not to
matter), it's likely to be more of a concern for the AsyncExitStack API,
where the "asyncio.iscoroutinefunction" introspection API is likely to be
quite helpful, as are other APIs like `asyncio.ensure_future()`.

So would folks be OK with my asking the author of the PR for
https://bugs.python.org/issue29679 (adding asynccontextmanager) to rewrite
the patch to add it as asyncio.contextlib.asyncontextmanager (with a
cross-reference from the synchronous contextlib docs), rather than the
current approach of adding it directly to contextlib?

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/20170301/345a8640/attachment.html>