[nomel]

> I suspect 3.14.4 could have been tweaked slightly to address the issue without a revert

I'm sure all the people that have been working on this for years would be interested in your small tweak, that they didn't think of, and would happily accept the PR!

[elfly]

Maybe they could have included an option to switch between GC implementations, like Java had done before.

Maybe in all those years they could have thought of that.

[favorited]

They did think of that, and decided it's not worth the maintenance burden.

https://discuss.python.org/t/reverting-the-incremental-gc-in...

[vlovich123]

The options are

a) do work to reduce issues as they come up b) appease the vocal complaints

A takes work, guts, and risk. Option b was chosen with the GC work basically saddled with so much process it’s never going to change. Python has a very storied history of being very committee driven design so the committee did the committee thing.

[scott_w]

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.

[vlovich123]

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

[scott_w]

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?"

[vlovich123]

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.

[scott_w]

Your argument is, frankly, idiotic. If a version of Windows, or any deployed software, has a performance regression, do you consider it “not a live product” because you didn’t personally install it yet?

I really don’t have words. When people bemoan the state of software engineering, your comment here is exactly what they’re talking about.

[evilturnip]

I do find the BDFL approach much better for language design. You might disagree with the direction of the language, but there is usually a "philosophy" or "taste" driven by one person that tends to be consistent over time.

In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.

[japhyr]

> In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.

If you're referring to the steering council, that group was created in response to Guido stepping down.

He stepped down partly in response to the changing nature of online discussions around changes to the language. He just didn't want to be at the center of every polarizing discussion anymore. I think he also recognized that the transition needed to happen at some point, and that was as good a time as any.