<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 6, 2017 at 5:57 PM, Raymond Hettinger <span dir="ltr"><<a href="mailto:raymond.hettinger@gmail.com" target="_blank">raymond.hettinger@gmail.com</a>></span> wrote:<span class=""></span><br><span class=""></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Of course, it makes sense that anything not specific to asyncio should go outside of asyncio.<br>
<br>
What I'm more concerned about is what the other places actually are.   Rather than putting async variants of everything sprinkled all over the standard library, I suggest collecting them all together, perhaps in a new asynctools module.<br></blockquote></div><br></div><div class="gmail_extra">That's a tough design choice. I think neither extreme is particularly attractive -- having everything in an asynctools package might also bundle together thing that are entirely unrelated. In the extreme it would be like proposing that all metaclasses should go in a new "metaclasstools" package. I think we did a reasonable job with ABCs: core support goes in abc.py, support for collections ABCs goes into the collections package (in a submodule), and other packages and modules sometimes define ABCs for their own users.<br><br></div><div class="gmail_extra">Also, in some cases I expect we'll have to create a whole new module instead of updating some ancient piece of code with newfangled async variants to its outdated APIs.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>