4 ms·

Python2 aside, judging by the rest of these posts, maybe it's just me but I haven't seen any problems with forwards compatibility in Python 3. That is, stuff wr

Python2 aside, judging by the rest of these posts, maybe it's just me but I haven't seen any problems with forwards compatibility in Python 3. That is, stuff written 5 years ago runs fine on 3.8. The only issues I've had is with virtual environments and pip freeze because some older Python versions relied on packages for features now in the Python standard library, but since we know how to spot those now that's not too bad of a fix. On the other hand, Python gives a growing and continuously maintained standard library and none of the headaches that, say the JS ecosystem gives. That said, not all of the features are great all the time. Async/await comes to mind, which adds a lot of complexity without the performance gains even senior programmers might expect. But overall, we're already using features in Python3.8 for projects, and have upgraded our instances to Python3.8 without issue. I guess it's possible we leave some pip dependencies in the dust because they may have some incompatible code with a future 3.x release, but we haven't had a problem before. Tests permitting, we'll do the same for 3.9 if we find something we like or might wait a few years.

nickysielicki 6y ago
> That is, stuff written 5 years ago runs fine on 3.8. The only exception to this that I can think of is the changes to generators introduced in PEP479. https://www.python.org/dev/peps/pep-0479/ https://www.python.org/dev/peps/pep-0479/ https://www.juandebravo.com/2018/11/09/python-37-stop-iteration/ https://www.juandebravo.com/2018/11/09/python-37-stop-iterat...
robocat 6y ago
> and none of the headaches that, say the JS ecosystem gives. ECMAScript is the language, and it is amazingly backwards compatible back 20 years to about the start of the century without any trouble, and plenty of tooling like TypeScript can target ECMAScript 3 released a score of years ago. Python could have added a ‘use strict’; in 3.0 to avoid a breaking change!? Sure, since then browser features have radically changed and frameworks have changed, but the language itself has been extremely solid. Conflating JS and the ecosystem is not a fair comparison. Also there have been many competing different implementations of JS engines, with amazing levels of compatibility between them (even Internet Explorer 5.5 released 2000 only had a few very minor known quibbles in the ECMAScript implementation). Edit: Of course Unicode is actually hard to deal with because ECMAScript uses UTF16 for strings and symbols, even though the source code is usually written in UTF8. And note that the u flag was added to RegExp expressions to deal with Unicode better in ES2015 (especially U+10000 and greater, which are generally difficult to deal with in ECMAScript code).
- CapriciousCptl 6y ago
  On a technical level, you're absolutely right, JS as a language has an amazing amount of backwards compatibility. So much that IE running on Win XP can run things that Babel compiles from ECMAScript X in 2020. But, the ecosystem is really something different entirely, and this isn't meant to be a slight to JS at all. It's just reality when running production code in 2020. Python's standard library is comprehensive, well-maintained and well-documented throughout. JS, by comparison, relies on packages from npm for the same features. Which means the issue my org has with the JS ecosystem is the stuff that's not built into the language spec or otherwise maintained by a central body, not that the things built into the language isn't standing the test of time or something like that. I hope that explains things.
  - robocat 6y ago
    > But, the ecosystem is really something different entirely Most of the ecosystem changes are driven by externalities - web-servers, browsers, developers. You can still choose to use an old web framework and it will work on modern browsers. That is entirely different from the Python 2.x -> 3.x change. The days of a simple CRUD web page delivered by a server are long gone. jQuery is still brilliant at adding adornment to HTML produced on a server. Putting your view and controller into JavaScript just makes sense. SPAs need completely different frameworks to support the highly complex needs of client-side rendering and interaction. Ten years ago component based renderers were not common and developer-friendly syntax hardly existed. Frameworks are being pushed by the needs of huge systems (Facebook), server side pre-rendering, and partial updates (correct term? to improve first load and responsiveness). Also the features available in a modern browser are radically different. Remember building up a string of HTML in JS for performance reasons? Avoiding the DOM because it was slow? So many features only started becoming reliable or available around Internet Explorer 11, yet now IE11 is hardly ever supported because it is missing critical features. An example is that in older Internet Explorer and Safari, you could theoretically update CSS rulesets from the DOM, but in practice doing anything dynamic risked crashes and memory leaks (even loading new CSS pages was difficult and error prone and browser specific e.g. detecting CSS load failures). Note: I was supporting the same JavaScript codebase for over a decade (initially IE5.5). There were no breaking changes in the ECMAScript, and very very few in the DOM (mostly driven by dropping IE specific DOM). The changes in the codebase were mostly driven by wanting to support new features in browsers.

nickysielicki 6y ago

> That is, stuff written 5 years ago runs fine on 3.8. The only exception to this that I can think of is the changes to generators introduced in PEP479. https://www.python.org/dev/peps/pep-0479/ https://www.python.org/dev/peps/pep-0479/ https://www.juandebravo.com/2018/11/09/python-37-stop-iteration/ https://www.juandebravo.com/2018/11/09/python-37-stop-iterat...

robocat 6y ago

> and none of the headaches that, say the JS ecosystem gives. ECMAScript is the language, and it is amazingly backwards compatible back 20 years to about the start of the century without any trouble, and plenty of tooling like TypeScript can target ECMAScript 3 released a score of years ago. Python could have added a ‘use strict’; in 3.0 to avoid a breaking change!? Sure, since then browser features have radically changed and frameworks have changed, but the language itself has been extremely solid. Conflating JS and the ecosystem is not a fair comparison. Also there have been many competing different implementations of JS engines, with amazing levels of compatibility between them (even Internet Explorer 5.5 released 2000 only had a few very minor known quibbles in the ECMAScript implementation). Edit: Of course Unicode is actually hard to deal with because ECMAScript uses UTF16 for strings and symbols, even though the source code is usually written in UTF8. And note that the u flag was added to RegExp expressions to deal with Unicode better in ES2015 (especially U+10000 and greater, which are generally difficult to deal with in ECMAScript code).

CapriciousCptl 6y ago
On a technical level, you're absolutely right, JS as a language has an amazing amount of backwards compatibility. So much that IE running on Win XP can run things that Babel compiles from ECMAScript X in 2020. But, the ecosystem is really something different entirely, and this isn't meant to be a slight to JS at all. It's just reality when running production code in 2020. Python's standard library is comprehensive, well-maintained and well-documented throughout. JS, by comparison, relies on packages from npm for the same features. Which means the issue my org has with the JS ecosystem is the stuff that's not built into the language spec or otherwise maintained by a central body, not that the things built into the language isn't standing the test of time or something like that. I hope that explains things.
- robocat 6y ago
  > But, the ecosystem is really something different entirely Most of the ecosystem changes are driven by externalities - web-servers, browsers, developers. You can still choose to use an old web framework and it will work on modern browsers. That is entirely different from the Python 2.x -> 3.x change. The days of a simple CRUD web page delivered by a server are long gone. jQuery is still brilliant at adding adornment to HTML produced on a server. Putting your view and controller into JavaScript just makes sense. SPAs need completely different frameworks to support the highly complex needs of client-side rendering and interaction. Ten years ago component based renderers were not common and developer-friendly syntax hardly existed. Frameworks are being pushed by the needs of huge systems (Facebook), server side pre-rendering, and partial updates (correct term? to improve first load and responsiveness). Also the features available in a modern browser are radically different. Remember building up a string of HTML in JS for performance reasons? Avoiding the DOM because it was slow? So many features only started becoming reliable or available around Internet Explorer 11, yet now IE11 is hardly ever supported because it is missing critical features. An example is that in older Internet Explorer and Safari, you could theoretically update CSS rulesets from the DOM, but in practice doing anything dynamic risked crashes and memory leaks (even loading new CSS pages was difficult and error prone and browser specific e.g. detecting CSS load failures). Note: I was supporting the same JavaScript codebase for over a decade (initially IE5.5). There were no breaking changes in the ECMAScript, and very very few in the DOM (mostly driven by dropping IE specific DOM). The changes in the codebase were mostly driven by wanting to support new features in browsers.