Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.14 garbage collection rigamarole

theconsensus.dev

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Python 3.14 garbage collection rigamarole

#11

Post by petre »

ameliaquining wrote: post #5
functionmouse wrote: post #2

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

It's better in some ways (order-of-magnitude reductions in pause times were cited) but worse in other ways (higher peak memory usage). That the higher peak memory usage was catastrophic for some users only became apparent through post-release feedback.

They should have shipped it as an addon GC, not enabled by default. One could have turned it on with a command line switch or an env var, just like the Ruby JIT.

Re: Python 3.14 garbage collection rigamarole

#12

Post by nomel »

vlovich123 wrote: post #7

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 tr…

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

Re: Python 3.14 garbage collection rigamarole

#13

Post by [deleted] »

moron4hire wrote: post #3
functionmouse wrote: post #2

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

It's this sort of stuff that leaves me scratching my head why people like Python so much. I hear them say they prefer the syntax and personally I feel like that's such a small part of the holistic experience of working with any particular language. It's one of the reasons why I gave up on C++ years ago for .NET, the whole system of tooling in .NET has never left me feeling like I was pigeonholed into doing things in…

[deleted]

Re: Python 3.14 garbage collection rigamarole

#14

Post by vlovich123 »

nomel wrote: post #12
vlovich123 wrote: post #7

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 tr…

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

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.

Re: Python 3.14 garbage collection rigamarole

#15

Post by evilturnip »

vlovich123 wrote: post #14
nomel wrote: post #12

Earlier quoted context omitted.

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

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.

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.

Re: Python 3.14 garbage collection rigamarole

#16

Post by zzzeek »

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.

Re: Python 3.14 garbage collection rigamarole

#18

Post by scott_w »

vlovich123 wrote: post #14
nomel wrote: post #12

Earlier quoted context omitted.

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

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.

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.

Re: Python 3.14 garbage collection rigamarole

#19

Post by Kwpolska »

SJC_Hacker wrote: post #6
moron4hire wrote: post #3

Earlier quoted context omitted.

It's this sort of stuff that leaves me scratching my head why people like Python so much. I hear them say they prefer the syntax and personally I feel like that's such a small part of the holistic experience of working with any particular language. It's one of the reasons why I gave up on C++ years ago for .NET, the whole system of tooling in .NET has never left me feeling like I was pigeonholed into doing things in…

Python is mostly about the “batteries included” standard library and what’s becoming nearly standard third party libs, being able to play around in the REPL,

The standard library is full of dead batteries. If the stdlib is so good, why does everyone install requests instead of using the stdlib http client? And why requests or something like it hasn't been adopted into stdlib after so many years of stability?

Re: Python 3.14 garbage collection rigamarole

#20

Post by Kwpolska »

hankbond wrote: post #9
moron4hire wrote: post #3

Earlier quoted context omitted.

It's this sort of stuff that leaves me scratching my head why people like Python so much. I hear them say they prefer the syntax and personally I feel like that's such a small part of the holistic experience of working with any particular language. It's one of the reasons why I gave up on C++ years ago for .NET, the whole system of tooling in .NET has never left me feeling like I was pigeonholed into doing things in…

It's easy to start learning on, or prototype with, and then sometimes momentum just keeps it going. Also it may not really be the best at anything, but it's "pretty good" at just about everything. It's kind of like vanilla ice cream. Packaging can be irritating although uv takes the sting out a bit. You are right that outside of verbosity, once you get used to the syntax of a language, the value of one over the other…

> Packaging can be irritating although uv takes the sting out a bit.

uv proves the OP’s point. Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv, and why is the Python package manager uv written in Rust and not Python?

Post reply on HN