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

[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?

Victor