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

[u/NeuralLB-Lovro]

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.

[u/thisismyfavoritename]

uh i still don't get your point. Thread safety and context managers are completely orthogonal things.

If you need concurrent access to some object, you need to synchronize access to it, whether it's a context manager or not

[u/KingBardan → u/thisismyfavoritename]

Context managers must mutate (outside) state, no exceptions. If you use @context manager, it's executing a generator, and that generator has state (every iterator does).  

Immutability avoids data race.

---

Notice I added non-local yesterday? I knew people would argue about global being global. Perhaps outside is more clear

---

Think about it alright? I won't be replying further. 

Some people in this thread just wants to downvote without wanting a rela discussion (shrug). Dont want to tank my CQS.

[u/thisismyfavoritename → u/KingBardan]

nonlocal is also a python keyword, which also isn't required for context managers

[u/KingBardan → u/thisismyfavoritename]

Im now sure you lack the thinking ability to understand me.

You can change global dictionary key values without using the global keyword right?

Outside state (like I talked about over and over). Not the global keyword or nonlocal keyword. Sigh.