I'm currently in a .NET shop so not an issue for me, makes me wonder if Python will eventually adopt the concept of LTS releases, this could have been avoided as an issue if it was part of a non-LTS release.
If all releases are LTS, then none are. Part of the point GP was making is that when some releases have a very short maintenance window, then changes that are terrible in them don't need to be reverted (since the maintenance window will close soon anyways).
It also serves as a soft signal that "hey this new feature, it might break things in unexpected ways even though it looks like it works!" so don't update until the next LTS which should encompass features that have been greenlit as stable, and have sat through a few releases.
Yeah it seems like a miss. I guess the thinking was that it wasn't developer-facing and just an internal optimization. But of course any change to garbage collection will change the memory and cpu dynamics of the process in a material way.
Makes ya miss having a BDFL. Dang I didn't realize he's 70 now.
https://en.wikipedia.org/wiki/Guido_van_Rossum
I wouldn’t recommend running the latest Python in prod. Honestly 3.x.7 releases are the most mature .
I'm currently in a .NET shop so not an issue for me, makes me wonder if Python will eventually adopt the concept of LTS releases, this could have been avoided as an issue if it was part of a non-LTS release.
All Python versions are LTS if you consider 5-year a good measure.
https://devguide.python.org/versions/
If all releases are LTS, then none are. Part of the point GP was making is that when some releases have a very short maintenance window, then changes that are terrible in them don't need to be reverted (since the maintenance window will close soon anyways).
It also serves as a soft signal that "hey this new feature, it might break things in unexpected ways even though it looks like it works!" so don't update until the next LTS which should encompass features that have been greenlit as stable, and have sat through a few releases.
Yeah it seems like a miss. I guess the thinking was that it wasn't developer-facing and just an internal optimization. But of course any change to garbage collection will change the memory and cpu dynamics of the process in a material way.
The lesson from this seems to be to handle this via PEP next time: https://discuss.python.org/t/reverting-the-incremental-gc-in...
It's not a change to the language, it's a change to the cpython runtime
problem is that Python is so centralized, CPython is essentially a "reference implementation"
PEPs aren't necessarily just for language changes, e.g https://peps.python.org/pep-0436/ which is largely a CPython implementation detail.
Exactly! Would like to understand more how that came about. PEP exists for a reason.