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

51–60 of 85 posts

Re: Python 3.14 garbage collection rigamarole

#51

Post by necovek »

zahlman wrote: post #28
necovek wrote: post #24

Earlier quoted context omitted.

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.

For a long time, urllib had everything deprecated except for the parsing code which remained relevant as the upstream RFCs have not changed IIRC.

Urllib2 is now also gone and mostly replaced with urllib.request.

It should cover 99% of the use-cases one would use requests for — I am not sure how and why it matters that it is a subpackage and not a top-level package?

This is just a natural evolution of a widely used language where you have to be careful with backwards compatibility.

Re: Python 3.14 garbage collection rigamarole

#52

Post by [deleted] »

tannhaeuser wrote: post #33

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

[deleted]

Re: Python 3.14 garbage collection rigamarole

#53

Post by rciorba »

watt wrote: post #34

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.

Because it's an implementation detail, not a change to the language itself. Similarly, when they re-implemented the dict type to preserve insert order, they also introduced it without a pep, because it was a side-effect of an implementation detail. Only later they decided people are so likely to depend on this, that they formalized it through a PEP.

Re: Python 3.14 garbage collection rigamarole

#54

Post by p_l »

_old_dude_ wrote: post #31

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 ?

Because people generally do not understand memory management, and by people I mean majority of programmers, leading to dumb tales about performance of GC vs RAII/manual or even glorifying RC

Re: Python 3.14 garbage collection rigamarole

#55

Post by moron4hire »

zahlman wrote: post #27
Kwpolska wrote: post #20

Earlier quoted context omitted.

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

Any claims that Python has a huge backwards compat mission go right out the window when you consider Python 3. 3 was a perfect chance to fix all of the major problems with Python, problems other languages have solved so there isn't even a need to invent things from scratch. They didn't and that's why the community is still split on adoption.

Re: Python 3.14 garbage collection rigamarole

#56

Post by Yossarrian22 »

moron4hire wrote: post #55
zahlman wrote: post #27

Earlier quoted context omitted.

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

Any claims that Python has a huge backwards compat mission go right out the window when you consider Python 3. 3 was a perfect chance to fix all of the major problems with Python, problems other languages have solved so there isn't even a need to invent things from scratch. They didn't and that's why the community is still split on adoption.

I don’t think there is still a Python 2 split, the lack of security updates being a concern

Re: Python 3.14 garbage collection rigamarole

#59

Post by vlovich123 »

scott_w wrote: post #18
vlovich123 wrote: post #14

Earlier quoted context omitted.

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.

The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect

Re: Python 3.14 garbage collection rigamarole

#60

Post by targafarian »

postdoc74 wrote: post #48
amelius wrote: post #44

Earlier quoted context omitted.

Python is the new Matlab and Mathematica combined.

Not anywhere near Mathematica, but a good replacement for Matlab. From a daily user of all those.

I forget who said it, but Python isn't the best at anything but it's decent to good at nearly everything, and that's why it's become so popular.

I do a lot of what I need symbolically in SymPy for dynamics analysis. Past that, I can't speak for it. At University I used Mathematica, but I just don't need all it can do at this point, so once again Python has proven to be "good enough." Matlab will be a similar story (e.g., I've never seen a good alternative to Simulink in Python).

But for everything else outside very specific domain tasks? Mathematica and Matlab are terrible for a lot of reasons. So I'll go out of my way to stay within the Python ecosystem, though I'm not afraid to pull out the specialty tools when I just can't make Python do the task near as well and/or nearly as quickly.

Post reply on HN