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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4