On 5 May 2018 at 07:59, Terry Reedy <tjreedy@udel.edu> wrote:
On 5/2/2018 5:11 AM, Victor Stinner wrote:
As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
the Move to Python 3" thread, I will like to clarify how a feature should be removed from Python.
Would it be possible (and sensible) to use the 2to3 machinery to produce 36to37.py, etc., to do mechanical replacements when possible and flag other things when necessary?
That capability actually exists in the python-future project (in the form of their "pasteurize" script, which takes idiomatic Python 3 code and turns it into Python 2.7 compatible code). One major issue though is that without a JIT compiler to speed things back up, the polyfills needed to target old versions in the general case (rather than when restricting yourself to a "backport friendly Python subset") are often either going to be unacceptably slow, or else unacceptably irritating to maintain, so folks have invested their time into figuring out how to ship their own runtimes in order to avoid being restricted by redistributors with slow runtime update cycles, and in being able to rely on PyPI packages rather than standard library packages. (That's very different from the incentives for browser vendors, who have users that expect them to be able to make arbitrary websites work, and blame the browser rather than the site when particular sites they want to use don't work properly) The other thing worth keeping in mind is that one of the core assumptions of JavaScript tooling is that debugging tools will be able to reach out to the internet and download additional files (most notably source maps) to help make sense of the currently running code. Without that ability to trace from compiled code back to the preferred source form for editing, making sense of an otherwise straightforward traceback can become a complex debugging exercise. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia