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

91–100 of 330 posts

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

#91

Post by kccqzy »

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.

You ask a machine to write your code and you still care about being easy to read?

In my experience the people who care the most about code readability tend to be the people most opinionated on having the right abstractions, which are historically not available in Go.

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

#93

Post by chuckadams »

pansa2 wrote: post #65
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.

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.

PHP does this as well. Most distributions ship PHP without thread safety, but it's seeing more use now that FrankenPHP uses it. Speaking of which, it would be nice if PHP's JIT got a little love: it's never eked out more than marginal gains in heavily-numeric code.

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

#94

Post by rjh29 »

pansa2 wrote: post #77
gjvc wrote: post #70

Earlier quoted context omitted.

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

The Python devs didn’t want to make huge changes because they were worried Python 3 would end up taking forever like Perl 6. Instead they went to the other extreme and broke everyone’s code for trivial reasons and minimal benefit, which meant no-one wanted to upgrade. Even the main driver for Python 3, the bytes-Unicode split, has unfortunately turned out to be sub-optimal. Python essentially bet on UTF-32 (with spac…

Ironically Perl 5 managed to do the bytes-Unicode split with a feature gate, no giant major version change.

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

#95

Post by thunky »

kccqzy wrote: post #91
JodieBenitez wrote: post #85

Earlier quoted context omitted.

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.

You ask a machine to write your code and you still care about being easy to read? In my experience the people who care the most about code readability tend to be the people most opinionated on having the right abstractions, which are historically not available in Go.

I don't think people mind reading Go as much as they mind writing it.

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

#96

Post by diziet_sma »

pansa2 wrote: post #77
gjvc wrote: post #70

Earlier quoted context omitted.

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

The Python devs didn’t want to make huge changes because they were worried Python 3 would end up taking forever like Perl 6. Instead they went to the other extreme and broke everyone’s code for trivial reasons and minimal benefit, which meant no-one wanted to upgrade. Even the main driver for Python 3, the bytes-Unicode split, has unfortunately turned out to be sub-optimal. Python essentially bet on UTF-32 (with spac…

> Python essentially bet on UTF-32 (with space-saving optimisations)

How so? Python3 strings are unicode and all the encoding/decoding functions default to utf-8. In practice this means all the python I write is utf-8 compatible unicode and I don't ever have to think about it.

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

#97

Post by kccqzy »

thunky wrote: post #95
kccqzy wrote: post #91

Earlier quoted context omitted.

You ask a machine to write your code and you still care about being easy to read? In my experience the people who care the most about code readability tend to be the people most opinionated on having the right abstractions, which are historically not available in Go.

I don't think people mind reading Go as much as they mind writing it.

Nah all the `if err != nil` is just so much noise they obscures the real logic. And for the longest time it didn’t have generics to write map/filter/reduce on slices, forcing people to use loops where the intention is less clear.

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

#98

Post by rtpg »

nvme0n1p1 wrote: post #86
rtpg wrote: post #83

Earlier quoted context omitted.

It's interesting you mention __del__ because Javascript not only doesn't have destructors but for security reasons (that are above my pay grade) but the spec _explicitly prohibits_ implementations from allowing visibility into garbage collection state, meaning that code cannot have any visibility into deallocations. I think __del__ is tricky though. In theory __del__ is not meant to be reliable. In practice CPython r…

> code cannot have any visibility into deallocations Doesn't FinalizationRegistry let you do exactly that? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Oh! While this one does mention that you don't have visibility, this + weak refs seem to change the game

I remember a couple of years ago (well probably around 2021) reading about GC exposure concerns and seeing some line in some TC39 doc like "users should not have visibility into collection" but if we've shipped weakrefs sounds like we're not thinking about that anymore

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

#99

Post by alpinisme »

nvme0n1p1 wrote: post #86
rtpg wrote: post #83

Earlier quoted context omitted.

It's interesting you mention __del__ because Javascript not only doesn't have destructors but for security reasons (that are above my pay grade) but the spec _explicitly prohibits_ implementations from allowing visibility into garbage collection state, meaning that code cannot have any visibility into deallocations. I think __del__ is tricky though. In theory __del__ is not meant to be reliable. In practice CPython r…

> code cannot have any visibility into deallocations Doesn't FinalizationRegistry let you do exactly that? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That link itself calls out that conformant implementations can’t be relied on to call callbacks.

> A conforming JavaScript implementation, even one that does garbage collection, is not required to call cleanup callbacks. When and whether it does so is entirely down to the implementation of the JavaScript engine. When a registered object is reclaimed, any cleanup callbacks for it may be called then, or some time later, or not at all. It's likely that major implementations will call cleanup callbacks at some point during execution, but those calls may be substantially after the related object was reclaimed. Furthermore, if there is an object registered in two registries, there is no guarantee that the two callbacks are called next to each other — one may be called and the other never called, or the other may be called much later. There are also situations where even implementations that normally call cleanup callbacks are unlikely to call them:

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

#100

Post by sheept »

diziet_sma wrote: post #96
pansa2 wrote: post #77

Earlier quoted context omitted.

The Python devs didn’t want to make huge changes because they were worried Python 3 would end up taking forever like Perl 6. Instead they went to the other extreme and broke everyone’s code for trivial reasons and minimal benefit, which meant no-one wanted to upgrade. Even the main driver for Python 3, the bytes-Unicode split, has unfortunately turned out to be sub-optimal. Python essentially bet on UTF-32 (with spac…

> Python essentially bet on UTF-32 (with space-saving optimisations) How so? Python3 strings are unicode and all the encoding/decoding functions default to utf-8. In practice this means all the python I write is utf-8 compatible unicode and I don't ever have to think about it.

UTF-32 allows for constant time character accesses, which means that mystr[i] isn't O(n). Most other languages can only provide constant time access for code units.
Post reply on HN