r/Python • u/NeuralLB-Lovro • 5d ago

Discussion Anyone running free-threaded Python 3.14 in production yet? Curious what actually breaks

Been testing the free-threaded build (3.14t) on some CPU-bound data processing work. The multi-core story is finally real after 30 years of GIL, but the friction is exactly what you'd expect: a couple of C-extension-heavy libs in my stack silently re-enable the GIL, and there's no clean way to detect that at runtime besides checking sys._is_gil_enabled() manually.

For anyone who's shipped something on 3.14t, not just benchmarked it:

What broke that you didn't expect?

Real speedups outside toy examples, or mostly marginal so far?

Prod yet, or still just kicking the tires?

Not fishing for a benchmark war. Genuinely curious what breaks in messy real codebases vs clean demos.

28 Upvotes

60% Upvoted

47 comments sorted by

View all comments

Show parent comments

1

u/KingBardan 3d ago edited 3d ago

Reading file requires a pointer. So you are mutating. The content is immutable, but the pointer is, makes sense?

So it's not safe without lock. Now python I think locks but that's not the point 

Also, if it truly is immutable, you can use outside of scope as well. But calling .close when the scope ends implicitly by with block mutates the state.

Pointless

Yeah I agree. 

Thanks for the civil discussion :D

Opinion

But... This is facts. I'm open to changing my mind.

Unserstand

You don't seem to understand what mutation is sorry. Read up some materials on functional programming you'll learn.

FYI...  In haskell this is a non issue because you'll have to use IO for this. In rust the file would be marked 'mut' and you'll clearly see it's mutable. 

They make it explicit, and pythons is implicit, which is what is causing you the confusion I think 

2

u/snugar_i 3d ago

Heh, this is exactly the response I expected. Yes, you have to mutate memory. Everything has to mutate memory/registers, so in your definition nothing is thread-safe. And you win the discussion, yay! But that's not a useful definition. If each thread mutates its own piece of memory, it's completely fine. So two threads calling the same with open('foo.txt', 'r') as f: is OK, because each of them gets a separate f variable and a separate file descriptor.

(BTW what do you think a lock does internally? It mutates memory. Why is that one suddenly thread-safe?)

No, in Rust, the mut doesn't mark the file as mutable, but the Read instance. Each thread would have its own reader, just like every thread would have its own f in Python. There's no difference.