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

21–30 of 85 posts

Re: Python 3.14 garbage collection rigamarole

#21

Post by necovek »

Kwpolska wrote: post #20
hankbond wrote: post #9

Earlier quoted context omitted.

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?

For the same reason GP posted and half the stdlib is written in C: Python is a language that is almost always good enough, but never really the best (and especially when it comes to performance of complex algorithms).

Re: Python 3.14 garbage collection rigamarole

#22

Post by pjmlp »

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…

C++ has vcpkg, conan, cmake and ninja nowadays.

They are as standard as arguing about Ant, Maven, Gradle in Java, npm, pnpm, yarn in node, and so on.

However I fully agree with the gist of your comment, basically Python is the new BASIC.

However at least BASIC was compiled, with exception of the 8 bit home micros.

Re: Python 3.14 garbage collection rigamarole

#23

Post by CamouflagedKiwi »

Kwpolska wrote: post #20
hankbond wrote: post #9

Earlier quoted context omitted.

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?

Because uv itself can fetch a Python distribution. If it's written in Python, it's quite a bit harder to distribute, assuming one of their goals is not to require an existing Python install.

Re: Python 3.14 garbage collection rigamarole

#24

Post by necovek »

Kwpolska wrote: post #19
SJC_Hacker wrote: post #6

Earlier quoted context omitted.

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?

Parts of requests has been adopted into stdlib: https://docs.python.org/3/library/urllib.request.html

People mostly defer to requests because they do not track language development closely and because we are creatures of habit.

I try to avoid non-stdlib packages when stdlib will do a good job, but I received negative feedback from people who aren't aware of the updates and couldn't foresee supply-chain attacks.

Re: Python 3.14 garbage collection rigamarole

#25

Post by picofarad »

zzzeek wrote: post #16

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

There was an issue recently with synapse, tbe matrix server implementation, where ram usage would grow until OOM.

The solution was to upgrade Python. But I won't, because that was the problem in the first place, here, apparently.

Oddly if I ran the whole thing under memray with a different allocator, no issue. I say oddly but it isn't.

So I guess my matrix server is broken until I rehome it on a new server with a fresh python instead of 3.10.8.

Re: Python 3.14 garbage collection rigamarole

#27

Post by zahlman »

Kwpolska wrote: post #20
hankbond wrote: post #9

Earlier quoted context omitted.

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?

> Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv

Incredibly large backward-compatibility burdens [0], internal politics [1] and general institutional dysfunction (no footnote; if you're familiar then you need no explanation, and if you aren't then the less said the better). Nothing to do with Python as a language. Most of the important pieces to get uv-like performance are algorithmic choices, and most of the rest are available as built-in C code in the reference implementation [2].

(Edit: wait, I recognize your username. You should definitely know these sorts of things.)

> why is the Python package manager uv written in Rust and not Python?

Because that's the language that Astral devs like, and because installing Python itself is considered in scope for uv so there would be an intractable bootstrapping issue.

[0]: In particular, the entire model of `setup.py` defining metadata is certifiably insane, especially when you consider the projects that expect to feed that code to Setuptools at build time in order to figure out what version of Setuptools is needed at build time. But this legacy approach is seen as something that absolutely must be guaranteed to work for well beyond even now; even attempts to remove long-deprecated, minor aspects of that functionality end up breaking major projects, including ones that didn't even require a build step in the first place [3].

[1]: Most obviously, GvR not wanting to have anything to do with it when initially approached by the SciPy people in IIRC 2011, leading to the creation of Conda). But a lot of other things, too. The backwards-compatibility issues synergize with this; consider for example the architectural dumpster fire of Setuptools, and the timeline of distutils removal from the standard library.

[2]: See e.g. my analysis in https://zahlman.github.io/posts/oxidation/ .

[3]: See e.g. my LWN article https://lwn.net/Articles/1020576/ .

Re: Python 3.14 garbage collection rigamarole

#28

Post by zahlman »

necovek wrote: post #24
Kwpolska wrote: post #19

Earlier quoted context omitted.

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?

Parts of requests has been adopted into stdlib: https://docs.python.org/3/library/urllib.request.html People mostly defer to requests because they do not track language development closely and because we are creatures of habit. I try to avoid non-stdlib packages when stdlib will do a good job, but I received negative feedback from people who aren't aware of the updates and couldn't foresee supply-chain attacks.

The current standard library urllib is a refactoring of previous attempts from the 2.x standard library, and urllib.request is just a sub-package. It does not represent adoption of requests; requests builds on urllib3, which was created to fill in gaps in what the standard library provided, and named like that because the 2.x standard library had both a `urllib` and a `urllib2` as they struggled to figure it out.

Re: Python 3.14 garbage collection rigamarole

#29

Post by zahlman »

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,

> “batteries included” standard library and what’s becoming nearly standard third party libs

Historically, the standard library made sense. And we're talking about a history that stretches back to before Internet connections were ubiquitous, to say nothing of connection speed.

Now the standard library is full of things that they refuse to remove because it would supposedly be too disruptive, but which they would never think of adding today if they weren't already there.

Re: Python 3.14 garbage collection rigamarole

#30

Post by zahlman »

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…

> Racket, CLisp

Syntax really does matter more than you give it credit for. Were that not the case, I'd expect one Lisp or Scheme dialect or other to take Python's place. Outside of that counterfactual, Python's competition was stuff like Ruby, and it turned out that network effects were also pretty important.

Post reply on HN