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

Koos Zevenhoven k7hoven at gmail.com
Fri Mar 10 11:44:37 EST 2017

On Wed, Mar 1, 2017 at 7:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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?

Related to this, here's a post from two years ago in attempt to tackle the cause of this problem (of needing async and non-async variants) and solve it in the long term.

https://mail.python.org/pipermail/python-ideas/2015-May/033267.html

You can read the details in that thread, but in short, the idea is that all functionality that may have to wait for something (IO etc.) should be explicitly awaited, regardless of whether the code takes advantage of concurrency or not. This solution is an attempt to do this without enforcing a specific async framework.

In the post, I made up the terms "Y end" and "L end", because I did not know what to call them. This was when the draft PEP492 was being discussed.

L is the end that 'drives' the (chain of) coroutines, usually an event loop. Y is the other end, the most inner co-routine in the calling/awaiting chain that does the yields. The L and Y end together could hide the need of two variants, as explained in the above link.

—Koos

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.ensurefuture(). 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

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com

--

More information about the Python-Dev mailing list