I suspect 3.14.4 could have been tweaked slightly to address the issue without a revert - they could have prioritized checking the liveliness of objects sorted by size. I’m pretty sure that would fix the max RSS issue without needing a revert and the people unhappy with 3.14 could keep using 3.13 or switch to 3.14 and simply inject explicit calls to gc.gc().

Figuring out how to measure the size of an object can be tricky of course, but I suspect there’s all sorts of things you could try including figuring out how much memory got deallocated after you gc a cycle and attributing it to where the object got allocated as a heuristic to measure the mean allocation size.

▲

nomel 4 hours ago | parent [-]

> 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!

▲

vlovich123 4 hours ago | parent [-]

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 2 hours ago \| parent \| next [-]
		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.
	▲	evilturnip 4 hours ago \| parent \| prev [-]
		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.