Python core team is reverting the 3.14 incremental GC due to significant memory pressure in production, restoring the generational GC from 3.13 in a 3.14 patch release and 3.15 alpha.
Key Takeaways
The incremental GC shipped in 3.14 without going through the PEP process, which is now cited as a root cause of insufficient evaluation.
Memory pressure reports from production environments triggered the revert; 3.14.5 will be released early to carry the fix.
3.15 is still in alpha, so the revert is low-risk there; an extra alpha 9 may ship if the revert lands within a week of the announcement.
A future incremental GC for 3.16 must go through the formal PEP process and more thorough evaluation before shipping.
Maintaining two GC implementations simultaneously in 3.14 was ruled out as too costly and risky.
Hacker News Comment Review
Commenters flagged the governance gap: a major runtime component shipped without a PEP, raising questions about oversight for similarly impactful changes like the JIT.
The .NET comparison surfaced: Microsoft’s internal dogfooding at scale gives their GC changes dense telemetry before release, something CPython lacks.
Concern centers less on the revert itself and more on how a problematic GC change reached a final release without adequate production-scale testing.
Notable Comments
@simonw: Free-threading (no-GIL) uses its own separate GC and is unrelated to this incremental GC revert.
@athoscouto: Confirmed real production impact; services showed continuous memory growth tracing back to aiohttp clients being recreated per request, surfaced via memray on 3.14.
