Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15's JIT is now back on track

fidget-spinner.github.io

Post reply on HN
Print view View original

111–120 of 330 posts

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

#111

Post by kelvinjps »

stmw wrote: post #20
ecshafer wrote: post #12

What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases? Ruby, PHP, JS. They all seemed to add JITs in significantly less time. A Python JIT has been asked for for like 2 decades at this point.

Some languages are much harder to compile well to machine code. Some big factors (for any languages) are things like: lack of static types and high "type uncertainty", other dynamic language features, established inefficient extension interfaces that have to be maintained, unusual threading models...

I think that it's just that python people took the problem different, they made working with c and other languages better, and just made bindings for python and offloaded the performant code to these libraries. Ex: numpy

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

#112

Post by brianwawok »

JodieBenitez wrote: post #85
thunky wrote: post #78

I always wanted this for Python but now that machines write code instead of humans I feel like languages like Python will not be needed as much anymore. They're made for humans, not machines. If a machine is going to do the dirty work I want it to produce something lean, fast, and strictly verified.

Pretty much my thoughts the other day... now that Codex does the writing, maybe I can finally switch to Go for the web backend stuff without being annoyed by some of its archaisms and gain significant execution performance, while still having a relatively easy to read language.

I have shifted as much as I can python to go when I don’t code. It’s just faster and the compiler catches more errors, win win,

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

#113

Post by brianwawok »

kelvinjps wrote: post #107
pansa2 wrote: post #88

Earlier quoted context omitted.

> Wouldn't this get the funding back? The funding was Microsoft employing most of the team. They were laid off (or at least, moved onto different projects), apparently because they weren't working on AI.

With Python being the main language for AI, isn't like more important to be more performant? I kinda don't get Microsoft reasoning, maybe they're just tight in money

I don’t think Python is the main language of AI.

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

#114

Post by gwking »

kzrdude wrote: post #64
zarzavat wrote: post #61

Earlier quoted context omitted.

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.

My understanding is that many extension modules are already written to take advantage of multithreading by releasing the GIL when calling into C code. This allows true concurrency in the extension, and also invites all the hazards of multithreading. I wonder how many bugs will be uncovered in such extensions by the free threaded builds, but it seems like the “nuts” choice actually happened a long time ago.

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

#115

Post by kstrauser »

rslashuser wrote: post #80

I'm curious is the JIT developers could mention any Python features that prevent promising JIT features. An earlier Ken Jin blog [1], mentions how __del__ complicates reference counting optimization. There is a story that Python is harder to optimize than, say, Typescript, with Python flexibility and the C API getting mentioned. Maybe, if the list of troublesome Python features was out there, programmers could know t…

Huh, I could imagine that as a set of Ruff rules:

> Using str.frobnicate prevents TurboJit on line 63

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

#116

Post by eru »

scorpioxy wrote: post #74
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.

The text encoding stuff wasn't a small change considering what it could break, at least. And remember we're sometimes talking about software that would cost a lot of money to migrate or upgrade. I still maintain some 2.x python code-bases that will be very expensive to migrate and the customer is not willing to invest that money. Although your general sentiment is something I agree with(if it's going to be painful do…

> I still maintain some 2.x python code-bases that will be very expensive to migrate and the customer is not willing to invest that money.

Slight tangent: if Claude can decimate IBM stock price by migrating off Cobol for cheap, surely we can do Python 2 to 3 now, too?

About the internals: we sort of missed an opportunity there, but back then there also didn't quite know what they were doing (or at least we have better ideas of what's useful today). And making the step from 2 to 3 even bigger might have been a bad idea?

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

#117

Post by smcl »

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.

I cannot believe people are still acting like Python 2->3 was a huge fuck-up and an enormous missed opportunity. When in reality Python is by most measures the most popular language and became so AFTER that switch.

Since the switch we have seen enormous companies being built from scratch. There is no reason for anyone to be complaining about it being too hard to upgrade in 2026

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

#118

Post by eru »

brianwawok wrote: post #113
kelvinjps wrote: post #107

Earlier quoted context omitted.

With Python being the main language for AI, isn't like more important to be more performant? I kinda don't get Microsoft reasoning, maybe they're just tight in money

I don’t think Python is the main language of AI.

Python is pretty big as glue in the AI ecosystem as far as I can tell. It also seems to be most agent's 'preferred' language to write code in, when you don't specify anything.

(The latter is probably more to do with the preferences they give it in the re-inforcement learning phase than anything technical, though.)

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

#119

Post by scorpioxy »

eru wrote: post #116
scorpioxy wrote: post #74

Earlier quoted context omitted.

The text encoding stuff wasn't a small change considering what it could break, at least. And remember we're sometimes talking about software that would cost a lot of money to migrate or upgrade. I still maintain some 2.x python code-bases that will be very expensive to migrate and the customer is not willing to invest that money. Although your general sentiment is something I agree with(if it's going to be painful do…

> I still maintain some 2.x python code-bases that will be very expensive to migrate and the customer is not willing to invest that money. Slight tangent: if Claude can decimate IBM stock price by migrating off Cobol for cheap, surely we can do Python 2 to 3 now, too? About the internals: we sort of missed an opportunity there, but back then there also didn't quite know what they were doing (or at least we have bette…

I wasn't aware that migrating projects off Cobol has become cheap and it would only take a Claude subscription.

In my experience, the problem had always been maintaining the business logic and any integrations with third-party software that also may be running legacy code-bases or have been abandoned. It can get quite complicated, from what I've seen. Now of course if you're talking about well maintained code-bases with 100%, or close to 100% test coverage, and that includes the integration part along with having the ability to maintain the user experience and/or user interface then yes it becomes a relatively easy process of "just write the code". But, in my experience, this has never been the case.

For the 2.x code-bases I maintain, the customers simply doesn't want to pay for any of it. They might choose to at a later time, but so far it has been more cost effective for them to pay me to maintain that legacy code than pay to have it migrated. Other customers have different needs and thus budget differently.

I'll refrain from judging if 2 to 3 was a missed opportunity or not. I believe the core team does actually know what they're doing and that any decision would've been criticized.

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

#120

Post by bawolff »

SahAssar wrote: post #59
bawolff wrote: post #53

Earlier quoted context omitted.

I thought php hasn't shipped jit yet (as in its behind a disabled by default config)

PHP 8 shipped with JIT on by default unless I'm mistaken.

https://www.php.net/manual/en/opcache.configuration.php says its off by default as of php 8.4 (and prior to that it was technically on but effectively off due to other configs)
Post reply on HN