On 23 Mar 2014 18:42, Martin v. Löwis firstname.lastname@example.org 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.