Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140606/a90c443e/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 6, 2014 at 8:47 AM, MRAB <span dir="ltr"><<a href="mailto:regex@mrabarnett.plus.com" target="_blank">regex@mrabarnett.plus.com</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"><div class="">On 2014-06-06 10:31, Victor Stinner wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
I added a new BaseEventLoop.is_closed() method to Tulip and Python<br>
3.5 to fix an issue (see Tulip issue 169 for the detail). The problem<br>
is that I don't want to add this method to Python 3.4 because usually<br>
we don't add new methods in minor versions of Python (future version<br>
3.4.2 in this case).<br>
<br>
Guido just wrote in the issue: "Actually for asyncio we have special<br>
dispensation to push new features to minor releases (until 3.5).<br>
Please push to 3.4 so the source code is the same everywhere (except<br>
selectors.py, which is not covered by the exception)."<br>
<br>
I disagree with Guido. I would prefer to start to maintain a<br>
different branch for Python 3.4, because I consider that only<br>
bugfixes should be applied to Python 3.4.<br>
<br>
</blockquote></div>
[snip]<br>
<br>
Isn't this a little like when bool, True and False were added to<br>
Python 2.2.1, a bugfix release, an act that is, I believe, now regarded<br>
as a mistake not to be repeated?<br></blockquote></div><br></div><div class="gmail_extra">It's a little like that, but it's also a little unlike that -- asyncio is explicitly accepted in the stdlib with "provisional" status which allows changes like this.<br>
<br></div><div class="gmail_extra">Regarding the workflow, I'd really like asyncio to be able to move faster than the rest of the stdlib, at least until 3.5 is fixed. Working in the Tulip repo is much easier for me than working in the CPython repo, so I'd like to keep the workflow of Tulip -> 3.4 -> 3.5 as long as possible. I also specifically consider selectors.py subject to a *different* workflow -- for that module the workflow should be 3.5 -> Tulip. If Tulip's update_stdlib.sh script's prompts to copy this file are too distracting, I can hack the script to be silent about this file if it detects that the CPython repo is 3.4.<br clear="all">
</div><div class="gmail_extra"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4