PyPy has been working for me for several years now

Original Article ↗ Hacker News Discussion ↗

PyPy, an alternative Python interpreter with a JIT compiler, is praised for delivering substantial speedups and long‑term reliability, yet many feel it remains underused and overshadowed by CPython. Commenters highlight persistent obstacles to broader adoption, including lagging support for some C/Fortran-backed libraries (like parts of the scientific stack), higher memory usage, and the dominance of CPython’s ecosystem and timelines. The conversation also touches on Python’s quirky naming culture—such as PyPy vs. PyPI and “wheels” from the old “Cheese Shop” metaphor—and how upcoming CPython efforts around JITs and free-threading may further shift the performance landscape.

Naming confusion and Python culture

  • Multiple commenters confuse PyPy (interpreter) with PyPI (package index); several needed rereads to realize the article wasn’t about packaging.
  • Some blame poor naming within the same ecosystem; others note historical ambiguity over which name came first, and that PyPI was long nicknamed “the Cheese Shop.”
  • “Wheel” terminology confuses some; others explain it as a “wheel of cheese,” i.e., a standard cheese form, not a Monty Python reference.
  • There’s a split between liking playful, punny names and preferring descriptive, low‑cognitive‑load names.

Perception of PyPy’s achievements

  • Many see PyPy as an under‑celebrated, long‑running “heroic” effort that has quietly delivered performance benefits for years.
  • Some recall very responsive maintainers and good real‑world speedups on heavier problems.
  • Others compare its ambition to projects like GraalVM or other visionary “high‑magic” runtimes.

Why PyPy didn’t take over

  • Key blockers cited:
    • Historically lagging behind CPython feature releases.
    • Incomplete or fragile support for C extensions and Cython, especially widely used libraries like NumPy and PostgreSQL drivers.
    • Larger memory footprint and delayed garbage collection behavior.
  • There is debate on how well it keeps up with CPython today; some say “pretty well,” others point to small contributor base and inevitable drift.
  • Some used PyPy successfully “for years” but hit hard limits once they needed C/Fortran‑backed scientific or DB libraries.

JIT, performance, and CPython relationship

  • One side argues CPython historically treated performance as a non‑goal, in contrast to PyPy, and only moved toward JITs under pressure from other languages and big vendors.
  • Another side emphasizes compatibility constraints and public, scheduled CPython development; they see JIT work as inherently hard rather than neglected.
  • There’s disagreement on whether JIT was PyPy’s primary goal from the start; project history is cited in both directions.
  • Some argue Python doesn’t need to compete as a JITted language at all; others counter that users will keep trying to use Python for everything regardless.

Other tools and ecosystems

  • Alternative or related efforts mentioned include Shedskin, Nuitka, and CPython enhancements like “Faster CPython” and no‑GIL work.
  • pipx is praised as a “silent hero” for managing Python CLIs cleanly, contrasted with the alphabet soup of pip/PyPI/pipenv/pyenv/PyPy.