A PEP that could quietly reshape the next decade of Python performance work is sitting at two upvotes. PEP 836 is the formal proposal to promote CPython's copy-and-patch JIT — an experiment that landed as an opt-in build flag in 3.13 — into a supported, first-class component of the interpreter. The cheeky "Go Brrr" title undersells what this actually represents: the moment CPython stops apologizing for the JIT and starts treating it as part of the shipped runtime.

Why this matters:

• Copy-and-patch is genuinely novel. Unlike a traditional tracing or method JIT (PyPy, V8, HotSpot), CPython's approach uses templates generated at build time from LLVM, then stitched together at runtime. The compile cost at runtime is nearly zero, which sidesteps the "startup penalty" problem that has historically kept JITs out of short-lived Python processes.
• It composes with the tier-2 optimizer and free-threaded builds. The interesting story of CPython 3.13–3.15 is three parallel bets — the JIT, the specializing adaptive interpreter, and the GIL-free build — all converging. A supported JIT is the piece that turns those bets into a coherent performance story instead of three research prototypes.
• The PEP itself is a governance artifact. Even if you don't care about compilers, the proposal likely defines the support contract: which platforms are tier-1, how the JIT interacts with C extensions and debuggers, what happens to profilers, and what the deprecation path looks like if the whole thing needs to be ripped out. Those are the questions Python core has been ducking for two years.
• Discourse threads are where the real design happens. By the time this appears in a release note, the interesting tradeoffs — build-time complexity, LLVM version pinning, binary size, sdist story — will have been argued out here first.

If you write Python at scale, maintain a distribution, ship a C extension, or just want to understand what "Python is getting fast" actually means at the implementation level, this thread is the primary source. The absence of comments on HN isn't a signal about quality — it's a signal that everyone who cares is reading discuss.python.org directly.