Python 3.14 garbage collection rigamarole

Related. 31 days ago

Reverting the incremental GC in Python 3.14 and 3.15

265 points, 130 comments

https://news.ycombinator.com/item?id=48077924

The usual GC tradeoff is between memory and CPU performance. If you set the memory max high, the GC will run less often, you get less pause time.

So I do not understand why it's a surprise that minimizing the pause time requires more memory. Is it because there is no knob to set either the max pause time or the max memory ?

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.

I see in the front page Pyodide 314.0 and now also Python 3.14. Is it a coincidence or is there some meaning to these "pi versions" in Python?

Do people use python for new projects apart from ML stuff which hasn't moved to all-native yet?

My experience with Python is a really bad one for professional work: it's chaotic and slow, and has by far the worst versioning and packaging story of any mainstream language, yet its proponents keep praising it in denial.

I guess Python is an ok target for agentic coding, but my god do look Claude's commit messages pretentious, with code bases quickly heading into absolute unmaintainability. At least it had found gross JS injection vectors in a Django app that really shouldn't have made it through a code review, architecture level as they were, but oh well. A mature Django app is also not a nice dev experience IMO, with tons of implicit behavior all over the place encoded in a mix of magic filenames, database naming conventions, and URL routing quickly descending into regexp hacks.

Anthony Sottile had a video on the reversion over a month ago: https://www.youtube.com/watch?v=tQ3hnQiJ0YM

Instead of "Reference counting primer" I would like to see a primer on how exactly such a huge change can go into Python without formal PIP process.

We definitely noticed behavioral differences in 3.14 regarding gc which could show up in particular test suites we have that are purposely ensuring all objects of a certain type were collected after a gc.collect() run. Between this and other issues (changes to the runtime API for typing, the first decently runnable version of free-threading, kind of a longer time for some C-based dependencies to catch up), the transition for my projects (SQLAlchemy) to 3.14 was generally more bumpy than that of say 3.12 or 3.13. will be interesting to see if 3.14.5 allows us to relax some changes we had to make to the test suite.

[dead]

[flagged]

The folks running the show as it relates to python remind me a lot about the folks running the show at mozilla.

That is not a compliment.

but I aways use Python to analysis my medical data.

> Python 3.14.0 introduced a new incremental garbage collector. But reports of higher memory usage caused the Python team to revert the garbage collector changes in 3.14.5.

If they didn't have very good objective reasons the new GC is better, they never should have shipped it. If they do, they should not have reverted the change.