Comment by scott_w
21 hours ago
Anyone who’s worked in incident response will tell you why you’re wrong.
Tweaking the GC while the system was functionally broken is the worst time to do it. Correct incident response is revert first, figure out how to fix it later.
The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect
You're simply incorrect here. The GC was in versions 3.14.0 to 3.14.4. See https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-inc...
On what planet is the currently released version of any software "not a live system?"
Do you live on a planet where the Python language maintainers are deploying Python into your servers or managing them? Do you live on a planet where a new version of Python being released gets instantly and automatically deployed into your systems without testing and validation?
You are responsible for that, not them. And if Python 3.13 is fine for you and you report a performance regression for 3.14, you can still stay on 3.13. And as you say, it was introduced in a new release. What happens when the other side goes and says “3.14.5 regressed on the GC pause times and my p95 web server latencies went up. Please revert”? At least one side can make the case “performance was changed on a major release of Python boundary” while the other is changing the performance on a minor release boundary. It’s an arbitrary decision that speaks to the politics of the organization and less about a well reasoned technical plan.