Python 3.15's JIT is now back on track • Hacker News Board

Re: Python 3.15's JIT is now back on track

#61

Post by zarzavat » Tue, Mar 17, 2026, 10:25 PM UTC

oystersareyum wrote: post #2

> We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track. I recently read an interview about implementing free-threading and getting modifications through the ecosystem to really enable it: https://alexalejandre.com/programming/interview-with-ngoldba... The guy said he hopes the free-threaded build'll be the only one in "3.16 or 3.17", I wonder if that sh…

I continue to believe that free-threading hurts performance more than it helps and Python should abandon it.

Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

Re: Python 3.15's JIT is now back on track

#62

Post by pansa2 » Tue, Mar 17, 2026, 10:29 PM UTC

saikia81 wrote: post #38

adrian17 wrote: post #7

I'm been occasionally glancing at PR/issue tracker to keep up to date with things happening with the JIT, but I've never seen where the high level discussions were happening; the issues and PRs always jumped right to the gritty details. Is there anywhere a high-level introduction/example of how trace projection vs recording work and differ? Googling for the terms often returns CPython issue tracker as the first resul…

have you read the dev mailing list? There the developers of python discuss lots.

There isn’t a dev mailing list any more, is there? Do you mean the Discord forum?

Re: Python 3.15's JIT is now back on track

#63

Post by __mharrison__ » Tue, Mar 17, 2026, 10:31 PM UTC

froobius wrote: post #54

echelon wrote: post #48

Earlier quoted context omitted.

It's a shame that Python 2->3 transition was so painful, because Python could use a few more clean breaks with the past. This would be a potential case for a new major version number.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

I would argue that the libraries, and specifically NumPy, are the reason Python is still in the picture today.

It will be interesting to see, moving forward, what languages survive. A 15% perf increase seems nice, until you realize that you get a 10x increase porting to Rust (and the AI does it for you).

Maybe library use/popularity is somewhat related to backwards compatibility.

Disclaimer: I teach Python for a living.

Re: Python 3.15's JIT is now back on track

#64

Post by kzrdude » Tue, Mar 17, 2026, 10:32 PM UTC

zarzavat wrote: post #61

oystersareyum wrote: post #2

> We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track. I recently read an interview about implementing free-threading and getting modifications through the ecosystem to really enable it: https://alexalejandre.com/programming/interview-with-ngoldba... The guy said he hopes the free-threaded build'll be the only one in "3.16 or 3.17", I wonder if that sh…

I continue to believe that free-threading hurts performance more than it helps and Python should abandon it. Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

I don't want to go too heavy on the negatives, but what's nuts is Python going for trust-the-programmer style multithreading. The risk is that extension modules could cause a lot of crashes.

Re: Python 3.15's JIT is now back on track

#65

Post by pansa2 » Tue, Mar 17, 2026, 10:38 PM UTC

zarzavat wrote: post #61

oystersareyum wrote: post #2

> We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track. I recently read an interview about implementing free-threading and getting modifications through the ecosystem to really enable it: https://alexalejandre.com/programming/interview-with-ngoldba... The guy said he hopes the free-threaded build'll be the only one in "3.16 or 3.17", I wonder if that sh…

I continue to believe that free-threading hurts performance more than it helps and Python should abandon it. Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

Maybe they could have two versions of the interpreter, one that’s thread-safe and one that’s optimised for single-threading?

Microsoft used to do this for their C runtime library.

Re: Python 3.15's JIT is now back on track

#66

Post by int_19h » Tue, Mar 17, 2026, 10:42 PM UTC

vlovich123 wrote: post #47

RussianCow wrote: post #32

Earlier quoted context omitted.

That makes sense if you're comparing with Java or C#, but not Ruby, which is way more dynamic than Python. The more likely reason is that there simply hasn't been that big a push for it. Ruby was dog slow before the JIT and Rails was very popular, so there was a lot of demand and room for improvement. PHP was the primary language used by Facebook for a long time, and they had deep pockets. JS powers the web, so there…

Google, Dropbox, and Microsoft from what I can recall all tried to make Python fast so I don’t buy the “hasn’t seen a huge amount of investment”. For a long time Guido was opposed to any changes and that ossified the ecosystem. But the main problem was actually that pypy was never adopted as “the JIT” mechanism. That would have made a huge difference a long time ago and made sure they evolved in lock step.

Microsoft is the one the TFA refers to cryptically when it says "the Faster CPython team lost its main sponsor in 2025".

AFAIK it was not driven by anything on the tech side. It was simply unlucky timing, the project getting in the middle of Microsoft's heavy handed push to cut everything. So much so that the people who were hired by MS to work on this found out they were laid off in a middle of a conference where they were giving talks on it.

Re: Python 3.15's JIT is now back on track

#67

Post by kccqzy » Tue, Mar 17, 2026, 10:44 PM UTC

froobius wrote: post #54

echelon wrote: post #48

Earlier quoted context omitted.

It's a shame that Python 2->3 transition was so painful, because Python could use a few more clean breaks with the past. This would be a potential case for a new major version number.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

Python does not take backwards compatibility seriously. 2 to 3 is a big compatibility break. But things like `map(None, seq1, seq2)` also broke; such deliberate compatibility break is motivated by no more than aesthetic purity.

Re: Python 3.15's JIT is now back on track

#68

Post by owaislone » Tue, Mar 17, 2026, 10:46 PM UTC

Oh man, Python 2 > 3 was such a massive shift. Took almost half a decade if not more and yet it mainly changing superficial syntax stuff. They should have allowed ABIs to break and get these internal things done. Probably came up with a new, tighter API for integrating with other lower level languages so going forward Python internals can be changed more freely without breaking everything.

Re: Python 3.15's JIT is now back on track

#69

Post by BarryMilo » Tue, Mar 17, 2026, 10:55 PM UTC

pansa2 wrote: post #60

froobius wrote: post #54

Earlier quoted context omitted.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

>> Python 2->3 transition > taking backwards compatibility so seriously Python’s backward compatibility story still isn’t great compared to things like the Go 1.x compatibility promise, and languages with formal specs like JS and C. The Python devs still make breaking changes, they’ve just learned not to update the major version number when they do so.

Indeed, Python's version format is semver but it's just aesthetics, they remove stuff in most (every?) minor version. Just yesterday I wasted hours trying to figure out a bug before realizing my colleague hadn't read the patch notes.

Re: Python 3.15's JIT is now back on track

#70

Post by gjvc » Tue, Mar 17, 2026, 10:57 PM UTC

owaislone wrote: post #68

Oh man, Python 2 > 3 was such a massive shift. Took almost half a decade if not more and yet it mainly changing superficial syntax stuff. They should have allowed ABIs to break and get these internal things done. Probably came up with a new, tighter API for integrating with other lower level languages so going forward Python internals can be changed more freely without breaking everything.

yes. it was not a massive shift. it was barely worth the effort.