On 23 Mar 2014 18:42, Martin v. L÷wis <martin@v.loewis.de> wrote:
> Am 23.03.14 08:07, schrieb Nick Coghlan:
> > Several significant changes in this revision:
> >
> > - scope narrowed to just Python 2.7 plus permission for commercial
> > redistributors to use the same strategy in their long term support
> > releases
> Thanks; the rationale is now much clearer, and also indicates yet
> another alternative path: fork Python.
> The PEP indicates that vendors are likely to fork Python anyway
> (as they always did, in a small scale). This could become more official
> and coordinated. Create an "enhanced TLS" clone of cpython, and start
> applying changes to 2.6, 2.7, and any other branches you consider
> relevant. Keep it merged with the cpython code base. This model
> has worked for many years for Stackless Python.
> Then, vendors have the choice of either releasing from the official
> CPython repository, or from the enhanced TLS one. All reasoning on
> application-level feature testing still applies: applications would
> have to feature-test whether they run on python.org release, or
> on an enhanced release.
> For Windows in particular, it would be up to ActiveState to decide
> whether they build binaries from python.org, or from the enhanced
> TLS repo. They could actually opt to provide both, leaving the choice
> to users.
> Even if this notion of forking is not acceptable, I suggest
> that you could still start working on the code in a separate clone,
> and the decision on the PEP could be deferred until a proposed
> implementation is ready. I see it as a risk of the PEP that the
> implementation might not be available before May 2015, in which
> case the PEP would become irrelevant.

Yes, a 2.7-enhanced-tls clone is definitely a good notion. Your suggestion to recast the entire PEP along those lines, so we always retain the option of choosing between them, also sounds plausible.


> Regards,
> Martin