<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Nick,</div><div class="gmail_quote"><br></div><div class="gmail_quote">First, thanks a lot for your detailed answer, it was very instructive to me.</div><div class="gmail_quote">My answers below.</div><div class="gmail_quote"><br></div><div class="gmail_quote">2016-07-03 6:09 GMT+02:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On 2 July 2016 at 16:17, Ludovic Gasc <<a href="mailto:gmludo@gmail.com">gmludo@gmail.com</a>> wrote:<br>
> Hi everybody,<br>
><br>
> I fully understand that AsyncIO is a drop in the ocean of CPython, you're<br>
> working to prepare the entire 3.5.3 release for December, not yet ready.<br>
> However, you might create a 3.5.2.1 release with only this AsyncIO fix ?<br>
<br>
</span>That would be more work than just doing a 3.5.3 release, though - the<br>
problem isn't with the version number bump, it's with asking the<br>
release team to do additional work without clearly explaining the<br>
rationale for the request (more on that below). While some parts of<br>
the release process are automated, there's still a lot of steps to run<br>
through by a number of different people:<br>
<a href="https://www.python.org/dev/peps/pep-0101/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0101/</a>.<br></blockquote><div><br></div><div>Thanks for the link, I didn't know this PEP, it was interesting to read.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
The first key question to answer in this kind of situation is: "Is<br>
there code that will run correctly on 3.5.1 that will now fail on<br>
3.5.2?" (i.e. it's a regression introduced by the asyncio and<br>
coroutine changes in the point release rather than something that was<br>
already broken in 3.5.0 and 3.5.1).<br>
<br>
If the answer is "No", then it doesn't inhibit the 3.5.2 rollout in<br>
any way, and folks can wait until 3.5.3 for the fix.<br>
<br>
However, if the answer is "Yes, it's a new regression in 3.5.2" (as in<br>
this case), then the next question becomes "Is there an agreed<br>
resolution for the regression?"<br>
<br>
The answer to that is currently "No" - Yury's PR against the asyncio<br>
repo is still being discussed.<br>
<br>
Once the answer to that question is "Yes", *then* the question of<br>
releasing a high priority fix in a Python 3.5.3 release can be<br>
properly considered by answering the question "Of the folks using<br>
asyncio, what proportion of them are likely to encounter problems in<br>
upgrading to Python 3.5.2, and is there a workaround they can apply or<br>
alternate approach they can use to avoid the problem?".<br>
<br>
At the moment, Yury's explanation of the fix in the PR is<br>
(understandably) addressed at getting the problem resolved within the<br>
context of asyncio, and hence just describes the particular APIs<br>
affected, and the details of the incorrect behaviour. While that's an<br>
important step in the process, it doesn't provide a clear assessment<br>
of the *consequences* of the bug aimed at folks that aren't themselves<br>
deeply immersed in using asyncio, so we can't tell if the problem is<br>
"Some idiomatic code frequently recommended in user facing examples<br>
and used in third party asyncio based libraries may hang client<br>
processes" (which would weigh in favour of an early 3.5.3 release<br>
before people start encountering the regression in practice) or "Some<br>
low level API's not recommended for general use may hang if used in a<br>
particular non-idiomatic combination only likely to be encountered by<br>
event loop implementors" (which would suggest it may be OK to stick<br>
with the normal maintenance release cadence).<br></blockquote><div><br></div><div>To my basic understanding, it seems to have race conditions to open sockets.</div><div>If my understanding is true, it's a little bit the heart of AsyncIO is affected ;-)</div><div><br></div><div>If you search about loop.sock_connect in Github, you've found a lot of results</div><div><a href="https://github.com/search?l=python&q=loop.sock_connect&ref=searchresults&type=Code&utf8=%E2%9C%93">https://github.com/search?l=python&q=loop.sock_connect&ref=searchresults&type=Code&utf8=%E2%9C%93</a><br></div><div><br></div><div>Moreover, if Yury, one of contributors of AsyncIO: <a href="https://github.com/python/asyncio/graphs/contributors">https://github.com/python/asyncio/graphs/contributors</a> and uvloop creator has sent an e-mail about that, I'm tented to believe him.</div><div>It's why a little bit scared by that, even if we don't have a lot of AsyncIO's users, especially with the latest release.</div><div><br></div><div>However, Google Trends might give us a good overview of relative users we have, compare to Twisted, Gevent and Tornado:</div><div><a href="https://www.google.com/trends/explore#q=asyncio%2C%20%2Fm%2F02xknvd%2C%20gevent%2C%20%2Fm%2F07s58h4&date=1%2F2016%2012m&cmpt=q&tz=Etc%2FGMT-2">https://www.google.com/trends/explore#q=asyncio%2C%20%2Fm%2F02xknvd%2C%20gevent%2C%20%2Fm%2F07s58h4&date=1%2F2016%2012m&cmpt=q&tz=Etc%2FGMT-2</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> If 3.5.2.1 or 3.5.3 are impossible to release before december,<br>
<br>
</span>Early maintenance releases are definitely possible, but the<br>
consequences of particular regressions need to be put into terms that<br>
make sense to the release team, which generally means stepping up from<br>
"APIs X, Y, and Z broke in this way" to "Users doing A, B, and C will<br>
be affected in this way".<br>
<br>
As an example of a case where an early maintenance release took place:<br>
several years ago, Python 2.6.3 happened to break both "from logging<br>
import *" (due to a missing entry in test___all__ letting an error in<br>
logging.__all__ through) and building extension modules with<br>
setuptools (due to a change in a private API that setuptools was<br>
monkeypatching). Those were considered significant enough for the<br>
2.6.4 release to happen early.<br></blockquote><div><br></div><div>Ok, we'll see first what's the decision will emerge about this pull request in AsyncIO.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> what are the<br>
> alternative solutions for AsyncIO users ?<br>
> 1. Use 3.5.1 and hope that Linux distributions won't use 3.5.2 ?<br>
<br>
</span>Linux distributions have mechanisms to carry patches (indeed,<br>
selective application of patches is one of the main benefits of using<br>
system packages over upstream ones), so any distro that rebases on<br>
3.5.2 can be encouraged to add the fix once it lands regardless of<br>
whether or not Larry approves an additional maintenance release<br>
outside the normal cadence.<br></blockquote><div><br></div><div>Good to know.</div><div>It means that it should be more Mac and Windows users who are concerned about this bug, especially new comers, because they download directly from <a href="http://python.org">python.org</a> website.</div><div>Depends on the pull request decision, it might be also a warning message on downloads page to explain to use 3.5.1 instead of 3.5.2 if you want to use AsyncIO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Cheers,<br>
Nick.<br>
<span class=""><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br></div></div>