Movatterモバイル変換


[0]ホーム

URL:


[Python-Dev] asyncio/Tulip: use CPython as the new upstream

Victor Stinnervictor.stinner at gmail.com
Fri Jun 6 11:31:23 CEST 2014


Hi,I added a new BaseEventLoop.is_closed() method to Tulip and Python 3.5to fix an issue (see Tulip issue 169 for the detail). The problem isthat I don't want to add this method to Python 3.4 because usually wedon't add new methods in minor versions of Python (future version3.4.2 in this case).Guido just wrote in the issue: "Actually for asyncio we have specialdispensation to push new features to minor releases (until 3.5).Please push to 3.4 so the source code is the same everywhere (exceptselectors.py, which is not covered by the exception)."I disagree with Guido. I would prefer to start to maintain a differentbranch for Python 3.4, because I consider that only bugfixes should beapplied to Python 3.4.It's not the first change that cannot be applied on Python 3.4 (onlyin Tulip and Python 3.5): the selectors module now also supportsdevpoll on Solaris. It's annoying because the Tulip script"update_stdlib.sh" used to synchronize Tulip and Python wants toreplace 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) asthe new asyncio "upstream". Bugfixes would be applied as other Pythonbugfixes: first in Python 3.4, than in Python 3.5. The"update_stdlib.sh" script of Tulip should be modified to copy filesfrom Python default to Tulip (opposite of the current direction).Workflow:New feature: Python 3.5 => Tulip => TrolliusBugfix: Python 3.4 => Python 3.5 => Tulip => TrolliusI 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, itdoesn't have the same constraints than Python stdlib.What do you think?Victor


More information about the Python-Devmailing list

[8]ページ先頭

©2009-2025 Movatter.jp