(original) (raw)

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.

Cheers,
Nick.

>
\> Regards,
\> Martin
\>
\>