asyncio/Tulip: use CPython as the new upstream
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. It's not the first change that cannot be applied on Python 3.4 (only in Tulip and Python 3.5): the selectors module now also supports devpoll on Solaris. It's annoying because the Tulip script "update_stdlib.sh" used to synchronize Tulip and Python wants to replace Lib/selectors.py in Python 3.4. I have to revert the change each time. I propose a new workflow: use Python default (future version 3.5) as the new asyncio "upstream". Bugfixes would be applied as other Python bugfixes: first in Python 3.4, than in Python 3.5. The "update_stdlib.sh" script of Tulip should be modified to copy files from Python default to Tulip (opposite of the current direction). Workflow: New feature: Python 3.5 => Tulip => Trollius Bugfix: Python 3.4 => Python 3.5 => Tulip => Trollius I don't think that Tulip should have minor release just for bugfixes, it would be a pain to maintain. Tulip is a third party module, it doesn't have the same constraints than Python stdlib. What do you think? Victor
On Fri, 06 Jun 2014 11:31:23 +0200, Victor Stinner
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.
It's not the first change that cannot be applied on Python 3.4 (only in Tulip and Python 3.5): the selectors module now also supports devpoll on Solaris. It's annoying because the Tulip script "update_stdlib.sh" used to synchronize Tulip and Python wants to replace Lib/selectors.py in Python 3.4. I have to revert the change each time.
I propose a new workflow: use Python default (future version 3.5) as the new asyncio "upstream". Bugfixes would be applied as other Python bugfixes: first in Python 3.4, than in Python 3.5. The "update_stdlib.sh" script of Tulip should be modified to copy files from Python default to Tulip (opposite of the current direction).
Workflow:
New feature: Python 3.5 => Tulip => Trollius Bugfix: Python 3.4 => Python 3.5 => Tulip => Trollius
I don't think that Tulip should have minor release just for bugfixes, it would be a pain to maintain. Tulip is a third party module, it doesn't have the same constraints than Python stdlib.
What do you think?
I don't have any opinion on the workflow. My understanding is that part of the purpose of the "provisional" designation is to allow faster evolution (read: fixing) of an API before the library becomes non-provisional. Thus I agree with Guido here, and will be doing something similar with at least one of the minor provisional email API features in 3.4.2 (unless I miss the cutoff again ... :( --David
Le 06/06/2014 07:00, R. David Murray a écrit :
I don't have any opinion on the workflow.
My understanding is that part of the purpose of the "provisional" designation is to allow faster evolution (read: fixing) of an API before the library becomes non-provisional. Thus I agree with Guido here, and will be doing something similar with at least one of the minor provisional email API features in 3.4.2 (unless I miss the cutoff again ... :(
I would personally distinguish API fixes (compatibility-breaking changes) from feature additions (new APIs). Regards Antoine.
On Fri, 06 Jun 2014 10:05:52 -0400, Antoine Pitrou
Le 06/06/2014 07:00, R. David Murray a écrit :
I don't have any opinion on the workflow.
My understanding is that part of the purpose of the "provisional" designation is to allow faster evolution (read: fixing) of an API before the library becomes non-provisional. Thus I agree with Guido here, and will be doing something similar with at least one of the minor provisional email API features in 3.4.2 (unless I miss the cutoff again ... :(
I would personally distinguish API fixes (compatibility-breaking changes) from feature additions (new APIs).
It doesn't look like the PEP directly addresses API changes in maintenance releases, and I suppose that should be fixed. I specifically want to fix this API before someone depends on it working the wrong way, which they would have to if I left it alone for the whole of the 3.4 series. (Issue 21091 for the curious.) --David
On 6 June 2014 19:31, Victor Stinner
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.
This is why PEP 411 was thrashed out: to let us split the dates of "make broadly available in the standard library" and "get ultra conservative with API changes". asyncio was added as a provisional module, so it can still get new features in 3.4.x maintenance releases - that's a far more minor change than the backwards compatibility breaks permitted by the PEP. The difference with selectors is that it was *not* added as a provisional module - it's subject to all the normal stability requirements. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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?
On Fri, Jun 6, 2014 at 8:47 AM, MRAB
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)
On Jun 06, 2014, at 04:47 PM, MRAB wrote:
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?
Yes, that was a mistake, but the case under discussion is different. With True/False, it was a runtime-wide change that affected every Python program, and there was no such "special dispensation". -Barry
participants (7)
-
Antoine Pitrou -
Barry Warsaw -
Guido van Rossum -
MRAB -
Nick Coghlan -
R. David Murray -
Victor Stinner