On 2014-06-06 10:31, Victor Stinner wrote:
Hi,

I added a new BaseEventLoop.is_closed() method to Tulip and Python
3.5 to fix an issue (see Tulip issue 169 for the detail). The problem
is that I don't want to add this method to Python 3.4 because usually
we don't add new methods in minor versions of Python (future version
3.4.2 in this case).

Guido just wrote in the issue: "Actually for asyncio we have special
dispensation to push new features to minor releases (until 3.5).
Please push to 3.4 so the source code is the same everywhere (except
selectors.py, which is not covered by the exception)."

I disagree with Guido. I would prefer to start to maintain a
different branch for Python 3.4, because I consider that only
bugfixes should be applied to Python 3.4.

[snip]

Isn't this a little like when bool, True and False were added to
Python 2.2.1, a bugfix release, an act that is, I believe, now regarded
as a mistake not to be repeated?

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.
">

(original) (raw)

On Fri, Jun 6, 2014 at 8:47 AM, MRAB <regex@mrabarnett.plus.com> wrote:
On 2014-06-06 10:31, Victor Stinner wrote:
Hi,

I added a new BaseEventLoop.is\_closed() method to Tulip and Python
3.5 to fix an issue (see Tulip issue 169 for the detail). The problem
is that I don't want to add this method to Python 3.4 because usually
we don't add new methods in minor versions of Python (future version
3.4.2 in this case).

Guido just wrote in the issue: "Actually for asyncio we have special
dispensation to push new features to minor releases (until 3.5).
Please push to 3.4 so the source code is the same everywhere (except
selectors.py, which is not covered by the exception)."

I disagree with Guido. I would prefer to start to maintain a
different branch for Python 3.4, because I consider that only
bugfixes should be applied to Python 3.4.

\[snip\]

Isn't this a little like when bool, True and False were added to
Python 2.2.1, a bugfix release, an act that is, I believe, now regarded
as a mistake not to be repeated?

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.


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.


--
--Guido van Rossum (python.org/\~guido)