Python Weekly #7: PEP 852 Proposes Native C Coroutines, Mimalloc Fix Slashes Free-Threaded RSS by 95%, print() Caching Boosts Throughput up to 66%

Python · Weekly #7

Python Weekly #7: PEP 852 Proposes Native C Coroutines, Mimalloc Fix Slashes Free-Threaded RSS by 95%, print() Caching Boosts Throughput up to 66%

pythonPythonWeeklyAsynchronous ProgrammingPerformance Tuning

Sources:GitHub Releases + 官方博客 + HN

Welcome to the 7th edition of the Python column in Tuanzi Tech Digest. This week (2026-11-02 to 2026-11-09), official Python maintenance enters a steady cadence following recent security updates; PEP 852 proposes a native asynchronous coroutine suite for the C API; CPython master landed a dense series of optimizations including print() single-character caching, mimalloc delayed free handling fixes for free-threaded mode, traceback object freelists, and a 64-bit carry refactor for bignum division; and the community engaged in extensive technical discussions regarding PEP 823 / 824 syntax extensions and the Tachyon standard library sampling profiler. Here is our breakdown of verified technical developments over the past seven days.

📦 Release Updates

Stable Release Status and Post-Incident Security Coordination Review

The current official stable mainline release is Python 3.15.2 (officially released on Oct. 25, 2026, signed by Release Manager Hugo van Kemenade). The previous-generation stable maintenance release is Python 3.14.10 (also released on Oct. 25, 2026). A review of official download and release pages indicates no new maintenance patches were issued in the past seven days. For an architectural deep dive into the 3.15 release, see our dedicated analysis: Python 3.15 Deep Dive; for prior branch developments, see Python 3.14 Deep Dive.

On November 5, the Python Software Foundation (PSF) published an emergency response retrospective on its official blog titled How the Python ecosystem responded to the eMudhra intermediate compromise. The report details coordination metrics and engineering mechanisms deployed by the security response team to neutralize compromised root and intermediate certificates:

  1. Response Timelines and Ecosystem Federation: PSF resident security developer Seth Larson coordinated with maintainers within 48 hours to push patches to certifi, CPython, pip, uv, sigstore, virtualenv, conda, pixi, manylinux, and gh-action-pypi-publish, alongside rebuilding container base images across PyPI infrastructure and official build fleets.
  2. Multi-Layer Certificate Interception Model: Beyond injecting hardcoded SPKI hash blocklists directly into the underlying _ssl C module across five active maintenance branches (including Python 3.15.2 and 3.14.10), client-side tooling established dual isolation by refreshing the certifi bundle. This ensures environments remain protected against machine-in-the-middle (MitM) attacks even if host operating system certificate stores lag behind.

Overview of actively maintained official branches:

BranchOfficial Release DateCategory & DistributionCore Status & Engineering Highlights
Python 3.15.2Oct. 25, 2026Latest Stable Mainline (Bugfix, Binaries provided)Built-in _ssl SPKI blocklist, runtime baseline stable, no unresolved release blockers
Python 3.14.10Oct. 25, 2026Previous Stable Branch (Bugfix, Binaries provided)Synchronized certificate blocklist, ensures smooth transition and backward compatibility
Python 3.13.18Oct. 25, 2026Security Maintenance Branch (Security, Source only)Only critical CVE patches and intermediate chain revocation logic backported
Python 3.12.16Oct. 25, 2026Security Maintenance Branch (Security, Source only)Eliminates transport security risks stemming from outdated OS CA bundles
Python 3.11.18Oct. 25, 2026Security Maintenance Branch (Security, Source only)Hardens foundational network layers across legacy deployment environments

📝 Deep Dives

PEP 852 Proposes Native Asynchronous Coroutine Suite for C API (PR #5217)

  • What happened: On November 2, CPython core developer Peter Bierma submitted the draft for PEP 852, proposing dedicated asynchronous primitives under PyAsync in Python.h for Python 3.16, introducing native C functions including PyAsync_New, PyAsync_AddAwait, PyAsync_SetResult, and PyAsync_Cancel.
  • Why it matters: CPython historically lacked a standardized C-level interface for defining and driving coroutines. Extension authors implementing asynchronous logic in C either had to bridge into event loops via pure-Python wrappers or manually hand-craft full generator state machines (the primary bottleneck preventing the mypyc compiler from supporting async syntax). PEP 852 abstracts coroutine lifecycles into opaque PyAsync handles, enabling native extensions to hook callbacks directly into the event loop without manually managing generator state machine transitions.
  • Who it affects: C/C++ native extension authors, Python compiler toolchains (such as mypyc, Cython, and PyO3), and developers building high-performance asynchronous networking engines.

CPython Master Refactors print(): Single-Bound Method and Cached Characters Yield 20% to 66% Speedup (gh-160725 / PR #160727)

  • What happened: On November 8, PR #160727 landed on CPython master. Previously, print() repeatedly looked up and created bound method instances of file.write for each positional argument, separator, and newline; furthermore, default delimiters sep=" " and end="\n" relied on PyFile_WriteString(), triggering redundant strlen() calls and UTF-8 validation on every invocation. The overhaul binds the write callable exactly once per print() invocation and emits interpreter-cached single-character unicode objects directly.
  • Why it matters: pyperf benchmarks demonstrate a geometric mean speedup of 1.20x across standard print() calls. Multi-argument invocations show dramatic gains: print('a', 1, 2.5) latency dropped from 996 ns to 687 ns (a 1.45x speedup, slashing CPU instructions by 31%); print(*range(10)) latency dropped from 2.86 µs to 1.73 µs (a 1.66x speedup, reducing CPU instructions by 39%); standard single-argument calls improved by 1.25x to 1.31x.
  • Who it affects: CLI utilities, batch processors, and pipeline services that log high volumes of unbuffered text to standard output.

Free-Threaded mimalloc Delayed Free Fix: Peak RSS Slashed Over 95% in Multithreaded Workloads (gh-161420 / PR #161533)

  • What happened: On November 7, PR #161533 was merged into CPython master. Following the upgrade to mimalloc 2.5.2, internal allocator logic in _mi_malloc_generic() was modified to process cross-thread delayed frees only once every 100 allocation calls. This resulted in abandoned memory blocks larger than 64 KiB accumulating indefinitely on individual thread heaps. The fix restores eager processing of cross-thread delayed frees on every allocation.
  • Why it matters: In GIL-free (free-threaded) concurrent workloads, Peak Resident Set Size (RSS) on Linux plummeted from 9,500–11,000 MiB down to 420–540 MiB; on macOS, peak memory dropped from 5,900–8,000 MiB to 410–500 MiB; and on Windows, memory shrank from 8,000–8,200 MiB to 430–450 MiB. This fix resolves artificial memory bloat in multithreaded free-threaded runtimes.
  • Who it affects: Systems engineers evaluating or operating free-threaded Python 3.15+ services across multithreaded, data-intensive workloads.

Traceback Freelist and 64-Bit Carry Refactor for Bignum Division Land on Master (gh-161242 / gh-160872)

  • What happened: CPython master merged two foundational data path improvements: PR #161243 introduced a dedicated freelist for exception traceback objects; PR #161156 widened the internal borrow variable zhi in Knuth Algorithm D bignum division loops to 64-bit stwodigits, eliminating redundant 32-to-64-bit type promotions.
  • Why it matters: Exception allocation overhead is noticeably reduced, accelerating raise ValueError benchmarks by 1.09x (latency dropping from 454 ns to 418 ns), while duck-typing inspection and dictionary fallback patterns in real-world libraries gained 2% to 6%; large integer division achieved a geometric mean speedup of 1.42x on AArch64 architectures (e.g., NVIDIA Grace / Neoverse V, with div 500/70 accelerating by 2.23x) and 1.21x on x86_64.
  • Who it affects: Developers of scientific computing, cryptography, and numerical libraries, as well as production systems relying on defensive try/except patterns.

🔥 Community Buzz

PEP 823 & 824 Operator Pair Submitted to Steering Council: Expressiveness vs. Parser Complexity (Discourse 117+ / 74+ Comments)

Authored by Marc Mueller and sponsored by Guido van Rossum, PEP 823 (None-aware access operators ?. and ?[]) and PEP 824 (None-coalescing operators ?? and ??=) completed revisions clarifying operator precedence and error messaging before formally being submitted to the Python Steering Council in early November. Dedicated Discourse discussion threads drew over 117 and 74 replies respectively.

Community discussion centered on three architectural dimensions:

  1. Defensive Boilerplate Reduction and Code Style: Proponents argue that traversing nested dictionaries and optional structures currently forces excessive nested if blocks or walrus expressions; ?? strictly checks against None, preventing or from erroneously catching valid falsy values like 0, "", or False. Opponents express concern that chainable access operators encourage loose, unstructured data modeling and erode Python’s principle of explicit design.
  2. Interactive Shell and Lexer Token Collisions: Interactive environments like IPython have long utilized trailing ? and ?? to inspect documentation and source code. Introducing ?. and ?? requires lexical tokenizers to disambiguate line-ending commands from multi-character operator expressions.
  3. Precedence Placement: PEP 824 sets the precedence of ?? below or and and (matching operator hierarchies in C#, JS, and PHP, rather than Swift/Kotlin where it ranks between binary and comparison operators). Dissenting contributors raised concerns that implicit short-circuiting could mask unintended side effects in nested function arguments.

Tachyon Built-in Sampling Profiler Sparks Comprehensive Evaluation: Standard Library vs. Dedicated Profilers (HN 50351453 / PR #161445)

Austin profiler author Gabriele Tornetta published The State of Python Profiling in 2026, analyzing the runtime observability landscape following the introduction of the built-in sampling profiler Tachyon in Python 3.15. On November 5, CPython master merged PR #161445, formally adding acknowledgments in standard library documentation and release notes to open-source pioneers including Austin, py-spy, and Pyflame.

Discussions around profiler adoption and overhead highlighted two key observations:

  1. Out-of-the-Box Convenience vs. High-Frequency Sampling: Tachyon embeds external statistical sampling into standard library distributions at a default rate of 1,000 Hz, enabling non-intrusive production tracing without third-party dependencies; however, for microsecond-level diagnostics, external tools like Austin scale up to 10,000 Hz while offering native C stack tracking and comprehensive asyncio task topology graphs.
  2. Statistical Sampling Replacing Deterministic Tracing: Historical benchmarks by the Scalene team showed traditional deterministic tracing via cProfile introduces up to 73% execution overhead while distorting short function call ratios. In contrast, external sampling profilers consistently cap CPU overhead below 2%. The community widely endorsed statistical sampling as the premier standard for production profiling and urged convergence on open formats like pprof and speedscope.

🔭 Next Week in Focus

  1. Steering Council Initial Feedback on PEP 823 / 824: The Council is expected to deliver its initial reaction regarding the necessity of syntactic coalescing and compatibility with interactive developer tooling.
  2. PEP 852 C API Coroutine Community Review: Core maintainers will begin architecture discussions on Discourse evaluating the PyAsync state machine design and its integration with existing Task schedulers.