[Python-Dev] API design: where to add async variants of existing stdlib APIs? (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Mar 1 20:20:08 EST 2017
- Previous message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Next message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Next message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]