3 ms·

You should never break backwards compatibility in a language. It's its undoing.

formerly_proven 6y ago
Yet. https://www.jetbrains.com/lp/python-developers-survey-2019/#PythonVersions https://www.jetbrains.com/lp/python-developers-survey-2019/#... https://www.jetbrains.com/research/python-developers-survey-2017/#python-3-adoption https://www.jetbrains.com/research/python-developers-survey-...
- sys_64738 6y ago
  Production code must be maintained. I've seen many shops with legacy 2.7 code that is stuck due to breaking compatibility in 3.x. Put it this way, if my production code suddenly needs to be patched due to non-security changes then that has to come out of somebody's budget. What else could we be doing with that budget than patching code from 2.7 to 3.8. How do you justify that to your budget director?
  - joshuamorton 6y ago
    "We can either do this now, slowly and carefully, or do it quickly and haphazardly when some dependency has a cve only patched in 3.x"
  - gtaylor 6y ago
    As long as you are willing to spend some of that budget continuously patching and maintaining the old 2.x interpreter to address security vulns as they are discovered (IF they are discovered), sure. No need to upgrade!
  - formerly_proven 6y ago
    If you haven't had the resources to port a codebase to a new language version over the course of twelve years, you clearly haven't had the resources to maintain it.
  - BeetleB 6y ago
    > What else could we be doing with that budget than patching code from 2.7 to 3.8. How do you justify that to your budget director? Can't speak for smaller businesses, but in larger companies, there is so much "waste" that the cost in $$$ to do this is insignificant in comparison. And if you choose to spread this effort out over, say, 5 years the annual cost is miniscule.
geofft 6y ago
Not only is this untrue in the case of Python, I think it's untrue in the case of basically every other successful language: - ANSI C was incompatible with pre-ANSI C. Current C has various minor incompatibilities like the removal of gets(). - bash defaults to non-backwards-compatible behavior and lets you set various shell options like "compat31" if you want it. - Newer version of the JDK generally require code fixes. - PHP has made various backwards-incompatible changes, like the removal of magic quotes in 5.4. There's also many more cases of languages getting forked in backwards-incompatible ways and going on to be successful. C++ is doing fine despite not being fully backwards-compatible with C; VB.NET broke compatibility with VB; zsh isn't POSIX-compatible by default; there were a million variants of BASIC back in the day, and still are a million variants of SQL; etc.

Yet. https://www.jetbrains.com/lp/python-developers-survey-2019/#PythonVersions https://www.jetbrains.com/lp/python-developers-survey-2019/#... https://www.jetbrains.com/research/python-developers-survey-2017/#python-3-adoption https://www.jetbrains.com/research/python-developers-survey-...

sys_64738 6y ago
Production code must be maintained. I've seen many shops with legacy 2.7 code that is stuck due to breaking compatibility in 3.x. Put it this way, if my production code suddenly needs to be patched due to non-security changes then that has to come out of somebody's budget. What else could we be doing with that budget than patching code from 2.7 to 3.8. How do you justify that to your budget director?
- joshuamorton 6y ago
  "We can either do this now, slowly and carefully, or do it quickly and haphazardly when some dependency has a cve only patched in 3.x"
- gtaylor 6y ago
  As long as you are willing to spend some of that budget continuously patching and maintaining the old 2.x interpreter to address security vulns as they are discovered (IF they are discovered), sure. No need to upgrade!
- formerly_proven 6y ago
  If you haven't had the resources to port a codebase to a new language version over the course of twelve years, you clearly haven't had the resources to maintain it.
- BeetleB 6y ago
  > What else could we be doing with that budget than patching code from 2.7 to 3.8. How do you justify that to your budget director? Can't speak for smaller businesses, but in larger companies, there is so much "waste" that the cost in $$$ to do this is insignificant in comparison. And if you choose to spread this effort out over, say, 5 years the annual cost is miniscule.

geofft 6y ago

Not only is this untrue in the case of Python, I think it's untrue in the case of basically every other successful language: - ANSI C was incompatible with pre-ANSI C. Current C has various minor incompatibilities like the removal of gets(). - bash defaults to non-backwards-compatible behavior and lets you set various shell options like "compat31" if you want it. - Newer version of the JDK generally require code fixes. - PHP has made various backwards-incompatible changes, like the removal of magic quotes in 5.4. There's also many more cases of languages getting forked in backwards-incompatible ways and going on to be successful. C++ is doing fine despite not being fully backwards-compatible with C; VB.NET broke compatibility with VB; zsh isn't POSIX-compatible by default; there were a million variants of BASIC back in the day, and still are a million variants of SQL; etc.