[Python-Dev] Process to remove a Python feature
Terry Reedy
tjreedy at udel.edu
Fri May 4 23:45:52 EDT 2018
On 5/4/2018 6:18 PM, Victor Stinner wrote:
> 2018-05-04 23:59 GMT+02:00 Terry Reedy <tjreedy at udel.edu>:
>> 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?
>
> I suggest you to watch Daniele Esposti's talk "Evolution or stagnation
> programming languages". He explains that Javascript is more successful
> than Python to introduce *language* evolutions thanks to transpiling
> (things like babel and polyfill):
> https://www.pycon.it/conference/talks/evolution-or-stagnation-programming-languages
I ran through the slides and found the babelsite. What I found: Babel
translates new code back to a sufficiently powerful and presumably
ubiquitous older version. It does so on a selectable feature basis
rather than a language version basis. (In other words, define your own
'new' version.) Polyfill supplies the backported new objects needed to
make the back translations run with new semantics.
This would be equivalent of defining, for instance, 2.7 as a base
version and having 3xbytesto27, 35asyncto27, etc for every new 3.x
feature. Some people wanted this, but, of course, 2.7 is *not*
installed everywhere. If Microsoft were to treat Python like it once
did Basic, and install it on all Windows machines, it would start with
recent 3.x.
Neither the slides nor site said anything about bug fixes and about the
need to have multiple versions of every function touched.
Because of the unique features of how Javascript is distributed and
used, I don't see how the Babel example would apply very well to Python.
--
Terry Jan Reedy
More information about the Python-Dev
mailing list