<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 March 2017 at 02:29, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mar 01, 2017, at 10:55 AM, Victor Stinner wrote:<br>
<br>
>I suggest to create 3rd party modules on PyPI. It became easy to pull<br>
>dependencies using pip and virtualenv.<br>
><br>
>It seems like <a href="https://github.com/aio-libs" rel="noreferrer" target="_blank">https://github.com/aio-libs</a> is the home of many asyncio<br>
>libraries.<br>
<br>
</span>This is what we did for aiosmtpd, an asyncio-based replacement for smtpd.<br>
It's worked out great on all fronts so far (good community contributions,<br>
rapid development, API flexibility as we move toward 1.0, good visibility<br>
inside the more general aio-libs umbrella).<br></blockquote><div><br></div></div>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 :)<br><br></div><div class="gmail_extra">My conclusion from the thread is:<br><br></div><div class="gmail_extra">- if it needs to depend on asyncio, it should either go in asyncio, or be published as a third party aio-lib<br></div><div class="gmail_extra">- if it *doesn't* need to depend on asyncio, then it's a candidate for stdlib inclusion (e.g. the coroutine support in inspect)<br></div><div class="gmail_extra">- both asynccontextmanager and AsyncExitStack actually fall into the latter category<br></div><div class="gmail_extra">- 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<br></div><div class="gmail_extra">- so for the specific case of contextlib, supporting both synchronous and asynchronous contexts in the one module makes sense<br></div><div class="gmail_extra">- I still plan to keep the test cases separate, since the async test cases need more infrastructure than the synchronous ones<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 <a href="https://github.com/asyncdef/aitertools">https://github.com/asyncdef/aitertools</a> that provide equivalent APIs for the asynchronous programming model.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>