9 ms·

My only bone to pick with this commentary is that it is 2020 and people are still complaining about Python as being unstable because of 2 -> 3. It was a rough

My only bone to pick with this commentary is that it is 2020 and people are still complaining about Python as being unstable because of 2 -> 3. It was a rough transition, to be sure. Python2 was released 20 years ago, and Python3 12 years ago. It is a pretty stable language.

gpm 6y ago
My housemate was just rolling back from python 3.8 to 3.7 yesterday due to a backwards incompatible change breaking a library... it's not just 2 -> 3 that makes python relatively unstable compared to rust.
- indolering 6y ago
  How does library breakage reflect on Rust? Python's deprecation policy is 2 years, only a year less than that of Rust's Epoch system.
  - gpm 6y ago
    Epoch's don't break libraries - that's the whole point. They manage this by allowing using a different epoch in a library than the application that uses it, and defaulting to the original epoch if you don't ask to use a new one. The vast majority of rust 1.0 libraries should still work with modern rust programs, I vaguely recall that there was one minor backwards incompatible change as of a result of memory safety bug (an exception to the guarantee), but I can't remember what it was and I can't find it with google so it might actually be all rust 1.0 libraries still work.
- alexanderdmitri 6y ago
  What the issue?
- yakubin 6y ago
  Yup, similar is 3.5->3.7. The community also doesn't seem to value backwards-compatiblity, judging from the libraries.
  - cpeterso 6y ago
    And I recently had to roll back from Python 3.9 to 3.7 to work around a couple different problems with the cffi and zstandard libraries on macOS 11.
duckerude 6y ago
It's specifically complaining about point releases of 3.x, it only mentions 2 in an unrelated way. The fix for https://bugs.python.org/issue40870 https://bugs.python.org/issue40870 caused me some grief when upgrading from 3.8.3 to 3.8.4 (though to be fair, the ast module has different stability guarantees).
johnmaguire 6y ago
I don't think the parent is talking about Python 2 -> 3. I think they are pointing out that for many developers, moving to Python 3 happened very late. That means they ran 2.7 since 2010 (roughly 10 years now.) Now that they are on 3.x, they get issues with each new 3.x release. The argument is that being on 2.7 for so long gave a false impression of the language being more stable than it is - developers just weren't using new versions.
- perryizgr8 6y ago
  Some people are still using 2.7 in production.
  - tutfbhuf 6y ago
    Maybe there will be a company like Red Hat that announces to support python 2.7 indefinitely, although I doubt it.
- bb88 6y ago
  Well to be fair the 2020 end of life date was announced almost a decade ago. That said, I know that fortune 500 companies that used 2.7 to develop new code in 2017 -- which was a mistake -- mostly because they were tied to old version of RHEL and they were too lazy to try to get Python 3 to work on an old version of RHEL. So 2020 rolled around and the pypi libraries they were using were no longer supported even though RHEL would support python 2.7. So yeah, it was a really bad experience for everyone involved.
the8472 6y ago
Some industries are very very slow when it comes to upgrades. E.g. the VFX reference platform[0] only adopted python 3 for the 2020 baseline, which means many recently released products are still embedding python 2.x [1]. [0] https://vfxplatform.com/ https://vfxplatform.com/ [1] https://vfxpy.com/ https://vfxpy.com/

gpm 6y ago

My housemate was just rolling back from python 3.8 to 3.7 yesterday due to a backwards incompatible change breaking a library... it's not just 2 -> 3 that makes python relatively unstable compared to rust.

indolering 6y ago
How does library breakage reflect on Rust? Python's deprecation policy is 2 years, only a year less than that of Rust's Epoch system.
- gpm 6y ago
  Epoch's don't break libraries - that's the whole point. They manage this by allowing using a different epoch in a library than the application that uses it, and defaulting to the original epoch if you don't ask to use a new one. The vast majority of rust 1.0 libraries should still work with modern rust programs, I vaguely recall that there was one minor backwards incompatible change as of a result of memory safety bug (an exception to the guarantee), but I can't remember what it was and I can't find it with google so it might actually be all rust 1.0 libraries still work.
alexanderdmitri 6y ago
What the issue?
yakubin 6y ago
Yup, similar is 3.5->3.7. The community also doesn't seem to value backwards-compatiblity, judging from the libraries.
- cpeterso 6y ago
  And I recently had to roll back from Python 3.9 to 3.7 to work around a couple different problems with the cffi and zstandard libraries on macOS 11.

duckerude 6y ago

It's specifically complaining about point releases of 3.x, it only mentions 2 in an unrelated way. The fix for https://bugs.python.org/issue40870 https://bugs.python.org/issue40870 caused me some grief when upgrading from 3.8.3 to 3.8.4 (though to be fair, the ast module has different stability guarantees).

johnmaguire 6y ago

I don't think the parent is talking about Python 2 -> 3. I think they are pointing out that for many developers, moving to Python 3 happened very late. That means they ran 2.7 since 2010 (roughly 10 years now.) Now that they are on 3.x, they get issues with each new 3.x release. The argument is that being on 2.7 for so long gave a false impression of the language being more stable than it is - developers just weren't using new versions.

perryizgr8 6y ago
Some people are still using 2.7 in production.
- tutfbhuf 6y ago
  Maybe there will be a company like Red Hat that announces to support python 2.7 indefinitely, although I doubt it.
bb88 6y ago
Well to be fair the 2020 end of life date was announced almost a decade ago. That said, I know that fortune 500 companies that used 2.7 to develop new code in 2017 -- which was a mistake -- mostly because they were tied to old version of RHEL and they were too lazy to try to get Python 3 to work on an old version of RHEL. So 2020 rolled around and the pypi libraries they were using were no longer supported even though RHEL would support python 2.7. So yeah, it was a really bad experience for everyone involved.

the8472 6y ago

Some industries are very very slow when it comes to upgrades. E.g. the VFX reference platform[0] only adopted python 3 for the 2020 baseline, which means many recently released products are still embedding python 2.x [1]. [0] https://vfxplatform.com/ https://vfxplatform.com/ [1] https://vfxpy.com/ https://vfxpy.com/