Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I see in the front page Pyodide 314.0 and now also Python 3.14. Is it a coincidence or is there some meaning to these "pi versions" in Python?by carra
- In Pyodide's new versioning scheme, the major version is the concatenated major and minor versions of the corresponding Python release. Pyodide 314 is based on Python 3.14 (which is just the fifteenth minor version of Python 3, counting from zero, and just happens to match the common approximation of pi).
- Anthony Sottile had a video on the reversion over a month ago: https://www.youtube.com/watch?v=tQ3hnQiJ0YMby zahlman
- 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 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.
by tannhaeuser - > apart from ML stuff
More and more applications need to use ML these days. So Python use will only grow.
by amelius - Half or more of the scientific research community live and breathe Python. Granted, it's Python 3.12, as 3.13 broke most of the C API, and everything COBOL and Fortran just about ground to a halt. But new projects are spun up constantly.by shakna
- I'm split on Django--it's ok but I don't love it.
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.
by nijave - I left the Python ecosystem some time ago.
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.
by quacker - Yeah I still use Python. I've been using it for a long time, I can get stuff done quickly with it, but I feel the same way you do to a big extent. Not sure what to use instead. I hate anything having to do with Javascript even though some parts of the JS world beat Python hollow (it's the other parts that are even worse than Python). Golang? Rust? Both too low level. I do use C++ (also low level) when I need something to run fast, but it's not the first stop. Erlang/Elixir? I like Erlang (haven't used Elixir) but it's too small a world and I'd want something with a serious type system if I'm gonna change languages. Haskell? Too much headache to do even simple things, such as logging. Scala? The bureaucracy of Java with the headaches of Haskell. OCaml? Maybe underrated and I should look into it more, but again it seems like Haskell's poorer cousin. I'm sure I'm overlooking some good ones though.
- It's the classic worse is better.
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.
by rurban - > 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.
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.
- 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.by watt
- 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.by rciorba
- 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 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.
by vlovich123 - > 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!
by nomel - 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 ?
by _old_dude_ - When GC runs less often, doesn't that rather increase the amount of things needed to be cleaned up _when_ GC finally runs? So actually the GC time _at that point_ should be longer, not shorter, while in total summed up, it should be shorter. Running GC often means cleaning up less stuff for every GC run, so the GC time for each run should be shorter.
Do I have any misconceptions?
by zelphirkalt - 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 RCby p_l
- Related. 31 days ago
Reverting the incremental GC in Python 3.14 and 3.15
265 points, 130 comments
by emil-lp - 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.by zzzeek
- 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.
by picofarad