[Python-Dev] asyncio/Tulip: use CPython as the new upstream (original) (raw)

R. David Murray rdmurray at bitdance.com
Fri Jun 6 13:00:40 CEST 2014

On Fri, 06 Jun 2014 11:31:23 +0200, Victor Stinner <victor.stinner at gmail.com> wrote:

Hi,

I added a new BaseEventLoop.isclosed() 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 "updatestdlib.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 "updatestdlib.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

More information about the Python-Dev mailing list