If using containers I believe this change was pushed in image python:3.14.5-slim-trixie
Reverting the incremental GC in Python 3.14 and 3.15
41–50 of 134 posts
Re: Reverting the incremental GC in Python 3.14 and 3.15
#42Earlier quoted context omitted.
And if people want python with java, there's always Jython.
Graal vm has support for python 3 unfortunately it’s funded by oracle.
If it makes you feel any better (it probably doesn't), the development of OpenJDK and the Java language itself is also mostly funded by Oracle
Re: Reverting the incremental GC in Python 3.14 and 3.15
#43Earlier quoted context omitted.
Why are you miffed about it? I legitimately hate reading golang with passion and find python to be pretty intuitive, outside of the odd ambitious list comprehensions. I worked in a golang shop for several years, so it's not just an familiarity situation either. We are just different. That's not something to be mad about.
[flagged]
We should all go back to writing assembly
Re: Reverting the incremental GC in Python 3.14 and 3.15
#44[flagged]
Re: Reverting the incremental GC in Python 3.14 and 3.15
#45"Python 3.14 shipped with a new incremental garbage collector. However, we’ve had a number of reports of significant memory pressure in production environments. We’ve decided to revert it in both 3.14 and 3.15, and go back to the generational GC from 3.13." Sounds the right move for me
The main benefit of python to me is that while slow, it's predictable. I do think they're going to get a lot more resistance to adding JITs, moving GCs, etc. it will become java with a million knobs to tune. If people want a JIT'd python just use pypy, right?
Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#46Earlier quoted context omitted.
nothing about the performance characteristics of python changed with AI so why would you use python over golang if performance is a requirement/bottleneck? Trying to understand the reasoning as to me golang and python are equally simple to write and understand.
Regardless of whether golang and python are actually equally simple, python certainly has the reputation of being easier to write and read than almost any other language. That is a big part of its popularity.
Python is not really simple though, the semantics are actually quite bonkers. It just has "simple"-looking syntax, but that only helps you for trivial programs where the bonkers semantics does not get in the way.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#47We've been impacted by this. I migrated our services to Python 3.14 so we could attach profilers during runtime. A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream S…
On profilers - profiling will come in 3.15, are you referring to remote exec? It is a great feature I am very exited about, at the same time afraid that the company won’t allow ptrace capability in prod.
yes. remote exec allows me to attach profilers (e.g. memray) directly into a running process. i'm also excited about the upcoming statistical (cpu) profiler from 3.15
Re: Reverting the incremental GC in Python 3.14 and 3.15
#48Earlier quoted context omitted.
And if people want python with java, there's always Jython.
Graal vm has support for python 3 unfortunately it’s funded by oracle.
Java is funded by Oracle, all of it.
People parrot to use OpenJDK without understanding it is mostly Oracle employees working on it.
And if you dislike Oracle, the other minor contributors are Red-Hat, IBM, SAP, Microsoft, Alibaba, Azul,... which for many HNers are the same.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#49.NET seems to have regularly changed the garbage collector over the years and I do not remember any similar surprises in production. I wonder why they have had better experience? I thought that by now dynamic garbage collection was a known quantity so that making changes, outside of out right bugs, is fairly safe and predictable?
One thing Microsoft does really well is eating its own dogfood and Microsoft feeds a ton of .Net dogs. So any change to GC starts with massive .Net MSFT code base so they get extremely good telemetry back about any downsides and might be able to fix it in time.
Did really well, unfortunately.
There is almost no dog fooding on Windows development since version 8, Typescript team rather rewrite the compiler in Go, Azure has plenty of Go, Rust and Java projects alongside .NET.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#50Earlier quoted context omitted.
[flagged]
We should all go back to writing assembly
No we should write one of the many modern programming languages that handle certain projects way better, including kotlin, go, or Java. The only things python is best in class at are scripting and as a harness for high performance c++ or fortran.