Python 3.14 is here. How fast is it?

Python’s Speed in Context

  • Benchmarks show Python 3.14 moderately faster than 3.9–3.13, but still ~1–2 orders of magnitude slower than Rust/C for tight numeric loops and naive recursive Fibonacci.
  • Free‑threaded (no‑GIL) builds give gains on multithreaded code but don’t change the fact that single‑thread interpreter speed is far behind JIT’d or compiled languages.
  • Several commenters note these microbenchmarks are pure‑Python arithmetic; real code often spends time in dicts/strings, ORMs, or C-backed libraries, which may behave differently.

“Does Python Need to Be Fast?”

  • Many argue Python’s value is ecosystem and ergonomics, not raw speed:
    • Huge library ecosystem (numpy/pandas/ML stacks), readable syntax, Jupyter, strong talent pool.
    • Often IO‑bound workloads (web APIs, DB access, disk/network) dominate, making interpreter speed irrelevant.
  • Others counter that performance does matter in practice:
    • Python web backends can bog down with ORMs or large table formatting.
    • Data import/parsing and glue code around “fast” libraries often become CPU bottlenecks.
    • At cloud scale, even a 2–4× gap vs Go/Rust/Java can mean significant hardware cost.

Language Positioning and Trade‑offs

  • Ongoing tension: should Python remain a dynamic “glue/prototyping” language with C/Rust backends, or chase Julia’s “one language” ambition?
  • Skeptics point out that large speedups likely require sacrificing dynamism or simplicity; incremental 10–20% gains won’t close a 30–100× gap.

PyPy vs CPython and the New JIT

  • PyPy impresses in these benchmarks (often much faster on pure Python), raising the question why it isn’t the default.
  • Obstacles cited:
    • Lags CPython by several versions; incomplete or fragile support for major C‑extension libraries (numpy/pandas/etc.).
    • Higher startup cost; uncertain benefit when most time is in native ML/num libraries anyway.
    • Limited funding and no “official” blessing, so momentum stays with CPython.
  • The new CPython JIT currently shows little improvement on the recursive test; several people stress this phase is about correctness and infrastructure, not big wins yet.

Free‑Threading / No‑GIL Work

  • No‑GIL CPython is a separate build; many C extensions must be audited or changed, hence it’s not the default.
  • Some hope for “GIL‑less C FFI,” but others note C extensions have long been able to manually release the GIL; the difficulty is making widespread, safe, concurrent use of shared objects.

Stability, Ecosystem, and Culture

  • Side debate compares TeX’s frozen “3.14” model with Python’s constant evolution; some wish more software prioritized long‑term stability over new features.
  • Strong praise appears for the broader Python ecosystem (Flask/Django, tutorials, tooling), even among critics of its performance.
  • Thread is peppered with “π‑thon”/“PiPy” jokes and some off‑topic logo and typography tangents.