Home Original page

[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