On Fri, Jun 6, 2014 at 8:47 AM, MRAB email@example.com wrote:
On 2014-06-06 10:31, Victor Stinner wrote:
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.
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.