On 5/4/2018 6:18 PM, Victor Stinner wrote:
2018-05-04 23:59 GMT+02:00 Terry Reedy <tjre...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
