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

[R. David Murray]

On Fri, 06 Jun 2014 11:31:23 +0200, Victor Stinner <victor.stinner at 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