On Fri, 06 Jun 2014 11:31:23 +0200, Victor Stinner <victor.stin...@gmail.com> 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. > > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
