Sorry, I didn't see this until just now. Maybe this should be discussed on python-dev, if you want a 3rd opinion?
On Tue, Jun 3, 2014 at 4:28 PM, Victor Stinner <[email protected]> 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 current 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 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). > > 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. > > What do you think? > > Victor > -- --Guido van Rossum (python.org/~guido)
