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.
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.
2 replies →
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.