3 ms·

Yes I think that was their takeaway, so now instead of having a slooooow migration we just have tens of libraries that break at every python update. Also there

by guappa 2y ago

Yes I think that was their takeaway, so now instead of having a slooooow migration we just have tens of libraries that break at every python update. Also there's no way to get access to pypi and fix the abandoned libraries. So they get patched in distributions and remain broken forever on pypi.

smcin 2y ago
Which libraries are you claiming break at every Python update? (3.12 or later)
- ChrisRackauckas 2y ago
  The last updates deleted modules from the standard library like distutils. Any library that used those modules is now broken.
  - smcin 2y ago
    But that's not "break at every Python update", I asked you to substantiate your claim "breaks at every Python update". distutils was deprecated and being phased out since 2014 [https://peps.python.org/pep-0632/ https://peps.python.org/pep-0632/]. It was removed in 3.12. People were preparing for this in 2021 already [https://news.ycombinator.com/item?id=26159509 https://news.ycombinator.com/item?id=26159509]. Python almost never does breaking changes in non-major versions, and only when necessary. And even at that, "Python" didn't break, only those (abandoned) packages that depend on distutils, and they already got/are getting fixed/removed. Honestly this isn't "breaks at every Python update". All those of us who aren't using those distributions don't even see the abandoned libraries in the first place. (I asked you guys for a list of the libraries.)
- IshKebab 2y ago
  It's not every Python update. 3.12 was particularly bad. Blessed is an example. I believe they had fixed it in the latest version, but we weren't using the latest version. Another example of breaking changes in the Python ecosystem: when Numpy updated to 2.0 (with breaking changes) we had a package that depended on `numpy >= 1.something` but it didn't actually work with Python 2.0. You can say "well they should have known to use the very unobvious non-default syntax 'numpy >= 1.0, < 2'" but even that isn't right because it turns out Python packages don't use semver; they just deprecate things and then remove them at arbitrary versions, so there's no reasonable upper bound you can actually put there.

by guappa 2y ago

smcin 2y ago

Which libraries are you claiming break at every Python update? (3.12 or later)

ChrisRackauckas 2y ago
The last updates deleted modules from the standard library like distutils. Any library that used those modules is now broken.
- smcin 2y ago
  But that's not "break at every Python update", I asked you to substantiate your claim "breaks at every Python update". distutils was deprecated and being phased out since 2014 [https://peps.python.org/pep-0632/ https://peps.python.org/pep-0632/]. It was removed in 3.12. People were preparing for this in 2021 already [https://news.ycombinator.com/item?id=26159509 https://news.ycombinator.com/item?id=26159509]. Python almost never does breaking changes in non-major versions, and only when necessary. And even at that, "Python" didn't break, only those (abandoned) packages that depend on distutils, and they already got/are getting fixed/removed. Honestly this isn't "breaks at every Python update". All those of us who aren't using those distributions don't even see the abandoned libraries in the first place. (I asked you guys for a list of the libraries.)
IshKebab 2y ago
It's not every Python update. 3.12 was particularly bad. Blessed is an example. I believe they had fixed it in the latest version, but we weren't using the latest version. Another example of breaking changes in the Python ecosystem: when Numpy updated to 2.0 (with breaking changes) we had a package that depended on `numpy >= 1.something` but it didn't actually work with Python 2.0. You can say "well they should have known to use the very unobvious non-default syntax 'numpy >= 1.0, < 2'" but even that isn't right because it turns out Python packages don't use semver; they just deprecate things and then remove them at arbitrary versions, so there's no reasonable upper bound you can actually put there.