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.
Some people just don't have the experience you do, "its proponent keep praising it in denial", can we have a better level of debate, come on now.
The slowest of all dynamic scripting languages. Breaking ABI's and API's left and right all the time. Not able to implement basic performance optims. Their infrastructure (pip) getting worse and worse, getting everyone to install private venv's for every app, leading to missing security updates, because updates just break everything.
People just love trouble.
Hi, I'm a pip maintainer, can you please report any issue you think is happening in recent versions of pip: https://github.com/pypa/pip/
I particularly work on performance and stability and think we've been making big strides over the last two years
> getting everyone to install private venv's for every app, leading to missing security updates, because updates just break everything.
venv's stop your OS tooling from breaking, Linux distro maintainers pushed Python packaging to not allow installing into the system packages by default, and they weren't wrong.
All these other problems are solved with proper use of a lock file (which are now standardized, and you can generate and install from them in the latest version of pip), and/or use a project tool (uv, poetry, etc.).
Reasons: The Python 2->3 transition, asyncio package, async/await function coloring, abysmal package management, the GIL and poor performance, breakage from version to version. I'm ambivalent on type hints. I regret nothing, especially after seeing how the GC and JIT projects have been handled.
Golang addresses all of my problems with Python. Native code, good performance, an exceptional toolchain, a built-in package solution, great concurrency support, and they prioritize compatibility across versions. AI is good at writing Golang (as good as any other language I've tried), and AI benefits a lot from static types.
I don't think it's chaotic. I won't deny it's somewhat slow however usually anything performance sensitive gets shoved in a native code extension anyway.
As for packaging, I haven't had any problems with poetry or uv. The only time I ever had issues was with Windows in corporate environments where wheels were unavailable and it was also basically impossible to get the right toolchain installed for native code. However, not being able to install a compiler is not really a Python problem
Claude Code has a setting to change the git template so it doesn't attribute itself or you can also commit manually.
3.14 broke GC
I guess these kinds of priorities are exactly why Python is not my favorite programming language and why you have tens of Python versions installed on any machine. Not to talk about the Python 2 -> 3 drama that was also about fetishising syntax and pureness over pragmatism, installed base, and respect for existing code.
More and more applications need to use ML these days. So Python use will only grow.
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'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!
Maybe in all those years they could have thought of that.
https://discuss.python.org/t/reverting-the-incremental-gc-in...
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.
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.
In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.
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 ?
Do I have any misconceptions?
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.
Reverting the incremental GC in Python 3.14 and 3.15
265 points, 130 comments
