How many lines of C it takes to execute a + b in Python

Original Article ↗ Hacker News Discussion ↗

Python’s simple expression `a + b` hides a large amount of C code and runtime machinery, from dynamic dispatch and magic methods to arbitrary-precision integers and hash-based attribute lookup. Commenters use this as a springboard to examine why CPython is relatively slow compared to JIT-based runtimes (like V8, LuaJIT, or PyPy), pointing to design choices such as pervasive object dynamism, the C API, and security-focused hashing. Many argue that Python excels as “glue” around fast C or C++ libraries rather than as a high‑performance compute engine, and that substantial speedups would require deep architectural changes rather than superficial tweaks.

Scope of the original question

  • Many note the article doesn’t actually answer “how many lines of C” run for a + b.
  • Several argue the notion is ill-posed: once you allow operator overloading (__add__/__radd__), a + b can do arbitrarily complex work.
  • Others suggest you could at least measure one concrete run using code coverage or profiling, but even that is path‑ and input‑dependent.

Dynamic dispatch, magic methods, and complexity

  • Discussion emphasizes how much machinery sits behind even simple operations in CPython: object model, dynamic dispatch via type slots, magic __dunder__ methods, descriptors, and exceptions for iteration.
  • Compared to languages like JS or Lua, Python exposes “magic” more pervasively on ordinary objects, making aggressive optimization and JITing harder.
  • Subclassing builtins (e.g., int) and custom descriptors further complicate specialization.

Performance, JITs, and design trade‑offs

  • Several commenters argue CPython is intentionally not performance‑focused; it optimizes for simplicity and C interop, and Python is best viewed as “glue” over fast native libraries.
  • Others counter that other dynamic languages (JS, LuaJIT, Smalltalk, Ruby JITs) show high performance is possible with enough engineering.
  • There’s debate whether Python’s language design or the C API and ecosystem are the main blockers to a top‑tier JIT.
  • Recent faster‑CPython work and external JITs (PyPy, Pyston) are mentioned; improvements so far are seen as real but modest compared to JS’s JIT revolution.

Hashing, security, and speed

  • A side thread revisits claims that changing Python’s hash function could double performance.
  • Multiple commenters dispute this: string hashes are cached, symbol names interned, and benchmarks that showed huge wins were criticized as unrealistic.
  • Python’s randomized SipHash (vs older FNV) is mainly for HashDoS resistance; performance impact in real workloads appears small.
  • Identity hashing for integers is discussed; it interacts with hash table implementation and can cause pathologies with certain integer distributions.

C vs Python ergonomics and “just use C”

  • Some suggest it might be “easier” to use C directly, but others stress Python’s drastically lower boilerplate and built‑in big‑int support.
  • Examples highlight how few lines of Python implement arbitrary‑precision arithmetic compared to the many lines of C or C++ needed to match behavior and safety.