I Analyzed Every Open Issue in CPython. Here's What I Found.

What does it look like to read through 7,154 open issues and 42,089 comments on the world's most popular programming language?

It looks like 23 MB of raw discussion text. It looks like bug reports from January 2003 that are still open. It looks like one developer who has personally commented on 912 separate issues. It looks like a median first-response time of six minutes -- and 760 issues that have never received a single comment.

I pulled every open issue and every comment from python/cpython on GitHub, wrote scripts to fetch and analyze the data in parallel, and spent days sifting through what I found. This is a snapshot of what CPython's issue tracker tells us about the health, velocity, and pressure points of one of the most widely used programming languages in the world.

The numbers tell a complicated story. Not one of decline or crisis -- CPython is faster, more active, and more ambitious than ever. But the data also shows a project where the backlog is growing faster than it can be resolved, where a handful of people shoulder a disproportionate share of the maintenance burden, and where bugs from two decades ago sit quietly next to bleeding-edge free-threading crashes.

Here's what the data shows.

How I Did This

All data was collected on February 11, 2026 via the GitHub REST API. The dataset includes:

• 
  7,154 open issues (pull requests excluded) with titles, bodies (up to 3,000 characters), labels, and metadata


• 
  42,089 comments across those issues, fetched in parallel using 15 concurrent workers with automatic rate-limit handling


• Issue bodies and comment text totaling 23 MB of discussion

Analysis was performed using keyword matching, label aggregation, temporal analysis, and pattern detection across all text -- titles, bodies, and comments. No machine-learning classifiers; just careful regex and counting. The scripts, raw data descriptions, and methodology are available in the repository so you can verify and extend the analysis.

One caveat: issues migrated from the old bugs.python.org tracker (pre-2022) may have incomplete comment histories. The oldest issues in particular should be interpreted with that context.

The Big Picture

Let's start with the broadest possible view.

Nearly half of all open issues (44.1%) are bugs. Over a third (35.7%) are feature requests. The remaining sliver includes 135 open crash reports, 79 security issues, and 1,232 issues that haven't been categorized at all -- a triage backlog in its own right.

The backlog isn't static. It's growing, and it's accelerating.

In 2015, CPython accumulated roughly 290 still-open issues per year. By 2020, that had nearly doubled to 530. In 2025, it hit 1,087 -- the highest single year ever. If you project the 2026 pace (144 issues in 6 weeks), the project is on track to exceed that record.

This doesn't mean CPython is falling apart. It means development velocity is increasing -- more features, more platforms, more contributors filing issues -- but resolution capacity isn't keeping pace. The backlog is a river that's widening faster than anyone can build bridges across it.

Where the Bugs Are

The standard library dominates everything. With 2,997 issues carrying a stdlib label, it accounts for 42% of all open issues. This shouldn't be surprising -- the stdlib is enormous, spanning everything from email parsing to GUI toolkits to multiprocessing -- but the concentration is striking.

Within the stdlib, three modules stand out as pain magnets:

• 
  IDLE: 289 issues. Python's built-in IDE is showing its age, with bugs ranging from clipboard handling (#84632) to dedenting with Shift+Tab (#38066 -- open since February 2003).


• 
  Multiprocessing: 279 issues. Deadlocks (#85880), race conditions on stdout flushing (#91776), and pool.terminate() hanging (#87129) are among the confirmed still-active reports.


• 
  Email: 253 issues. The email module has been accumulating bugs since the early 2000s. Inconsistent newline handling (#40414) has been open since June 2004. Invalid RFC2047 encodings (#142424) are still being filed in 2025.

Windows: The #1 Platform Pain

Platform-specific issues tell a clear story:

Windows has four times more platform-specific issues than macOS. Issues range from webbrowser.open being incomplete (#52479, 55 comments), to tempfile misinterpreting access-denied errors (#66305, 53 comments), to the long-requested python3 executable for Windows (#99185, 48 comments).

The emerging platforms are worth watching. Android (11 issues), iOS (6), WASI (6), and Emscripten (6) have small counts, but they represent CPython's expanding platform ambitions -- and each new platform brings its own class of bugs. Five years ago, these platforms had zero CPython issues. Their presence in the tracker at all signals a fundamental expansion of what CPython is trying to be: not just a server-side and scripting language, but a runtime that works everywhere, from iPhones to WebAssembly.

How Fast Does CPython Respond?

This is where the data gets genuinely impressive.

Yes, the median first response time is six minutes. That's not a typo.

64% of issues receive their first comment within one hour. 84% get a response within a day. This is exceptional for an open-source project of this scale and reflects a combination of active triagers, bots, and core developers who file issues and immediately begin commenting on them.

But that average -- 467 hours -- tells a different story. It's skewed by a long tail of neglected issues. 210 issues waited over three months for any response. And then there are the 760 issues -- 10.6% of the total -- that have never received a single comment.

The 760 Ghost Issues

The oldest uncommented issues date to the tracker migration from bugs.python.org:

Some of these may have had comments on the old tracker that didn't migrate. But the newer uncommented issues represent a genuine gap: someone took the time to report a problem, and nobody responded. That's the kind of experience that discourages potential contributors. A first-time bug reporter who gets no acknowledgment within a week may never file a second issue. At scale, 760 unanswered issues represent hundreds of potentially lost community members.

The comment distribution overall follows a predictable pattern:

The bulk of issues (54%) have 1-5 comments -- enough for a report and brief discussion but often not resolution. 328 issues have 20+ comments, typically indicating contentious decisions or complex debugging. Only 32 issues have cracked 50 comments, and those are the marathon debates we'll get to shortly.

Who Keeps CPython Running?

Core developers write 34.8% of all comments -- 14,636 out of 42,089. That means roughly one in three comments on CPython issues comes from someone with commit access. The other 65% comes from the broader community: users reporting bugs, contributors offering patches, and bystanders weighing in on design debates.

But within that core group, the distribution is extremely concentrated.

The Top 15

Serhiy Storchaka has commented on 912 separate issues -- nearly 13% of every open issue in the tracker. Terry Reedy has engaged with 708. Victor Stinner with 473. These three people alone have written 4,622 comments across 2,093 issues.

Guido van Rossum, Python's creator, remains active with 470 comments across 176 issues. He's the 12th most active commenter on open issues, still weighing in on language design and edge cases decades after stepping down as BDFL.

The Bus Factor

The top 5 commenters have written 6,418 comments -- 15% of all discussion on open CPython issues. The top 10 account for 9,699 comments (23%). This is a bus factor problem. If Serhiy Storchaka took a sabbatical, 912 issues would lose their most engaged reviewer. If Terry Reedy stepped back from IDLE, 289 IDLE issues would lose their primary maintainer.

The top issue reporters tell a related story. The people filing the most issues are almost exclusively core developers:

This means much of the backlog is self-identified technical debt -- problems the core team knows about but hasn't had time to fix. It's not primarily a flood of external user complaints. The people closest to the code are the ones documenting what needs work. In a sense, CPython's large issue count is a sign of self-awareness: the developers are rigorous about tracking problems, even when they know it will be months or years before anyone gets to them. A less disciplined project might just not file the issue.

What People Are Saying

Beyond who's commenting, what are they actually saying? Pattern analysis across all 42,089 comments reveals the texture of CPython's discussions:

A few things jump out.

27.5% of issues have had someone attempt a fix. Nearly 2,000 issues have at least one PR or patch referenced in the comments. That's a healthy sign -- but it also means 72.5% of open issues have no associated code contribution at all.

Disagreement outweighs agreement: 23.4% vs 19.0%. More issues contain pushback than support. This isn't necessarily bad -- healthy technical debate is how good software gets made -- but it suggests that decision friction is a real factor in why issues stay open. Some debates never reach consensus and nobody has the authority (or willingness) to make a final call.

649 issues have workarounds but no fix. That's 9.1% of all open issues where someone has said, in effect, "here's how to route around this bug." These are confirmed real-world pain points where users are living with broken behavior.

349 issues have close suggestions. The community itself thinks nearly 5% of the backlog should be shut down. A dedicated triage sprint targeting these could meaningfully shrink the issue count.

Reproduction gap: 5.4% confirmed vs 2.3% not reproduced. Most bugs lack any reproduction confirmation one way or the other, making it hard for maintainers to prioritize. Of the 3,155 open bugs, only 383 have explicit "I can reproduce this" confirmation in the comments, and only 162 have "cannot reproduce." That leaves roughly 83% of bugs in a limbo where nobody has publicly confirmed or denied the report. For maintainers trying to decide where to spend their limited time, this absence of signal is itself a problem.

255 issues report regressions. These are things that used to work and now don't -- arguably the highest-priority class of bug. Some are recent (3.14 regressions generating active discussion), but others have been flagged as regressions for years without being fixed.

The Hottest Debates

What are people arguing about right now? Here are the most actively discussed issues since January 2025:

The patterns in the 2025 hot issues reveal CPython's current priorities:

Compiler and optimizer work dominates. #126835 (moving const folding to the peephole optimizer) is the most active issue of 2025 with 122 comments from just 5 participants -- a deep, intense technical discussion. #131798 (better uop coverage in the JIT optimizer) reflects the push to make Python faster.

3.14 regressions are generating urgent traffic. A memory leak in the SSL library (#142516), a SIGSEGV in datetime.timedelta (#132413), slot dataclasses leaking (#135228), and stack overflow detection conflicts with C++ Boost (#139653) are all active regressions being debugged.

Infrastructure modernization questions are drawing community interest. Should CPython use zlib-ng instead of zlib (#91349, running since 2022 with 57 comments)? Should vendored modules be moved to a vendor directory (#129222)? Should every __pycache__ folder get a .gitignore (#141081)?

The All-Time Most Debated

The longest-running discussions are a different category -- often API design disagreements where the community is split:

There's a telling contrast here. Broad debates (many participants) tend to be API design issues: .pth file security (29 people), argparse dash handling (28 people), datetime nanosecond support (24 people). Deep debates (many comments, few participants) tend to be implementation details: const folding optimization (122 comments from 5 people).

The .pth file discussion (#78125) is perhaps the most emblematic. 123 comments from 29 participants, spanning years, about whether Python should allow arbitrary code execution in .pth files at interpreter startup. It touches on security, backwards compatibility, packaging workflows, and the fundamental question of how much the language should trust its own ecosystem. There's no easy answer, which is why the issue is still open.

The argparse issue (#53580) has been open for over a decade with 87 comments from 28 participants. The problem is simple to describe -- argparse rejects options that take arguments beginning with a dash, a regression from the older optparse module. The fix is not simple, because changing the parser's behavior would break existing code that relies on the current (broken) behavior. It's a perfect example of how backwards compatibility concerns can freeze even obvious bugs in place.

Then there's datetime nanosecond support (#59648). With 73 comments from 24 participants, this issue reflects a genuine gap: Python's datetime module is limited to microsecond precision in a world where nanosecond timestamps are increasingly common in databases, financial systems, and scientific computing. The discussion has run for years without resolution, partly because any change to datetime risks breaking the enormous ecosystem of code that depends on it.

The New Frontiers

Three major initiatives are reshaping CPython and creating new categories of issues:

Free-Threading (no-GIL)

• 
  99 issues mention free-threading in their discussions


• 
  71 issues carry the topic-free-threading label


• Growing rapidly as Python 3.13+ ships with experimental free-threading support

The free-threading effort is exposing an entire class of bugs that were masked by the GIL. TSAN failures in PyO3 tests (#130421), Thread._handle breaking third-party code (#132578), and new race conditions in the interpreter are all symptoms of removing a lock that has protected CPython (and papered over thread-safety bugs) for 30 years.

Threading-related discussions already account for 13.4% of all issue comment text -- and this number is climbing. As free-threaded Python moves from experimental to default in future releases, expect this to become the dominant source of new issues.

JIT Compiler

• 
  58 issues carry the topic-JIT label


• Active work on uop coverage (#131798), executor lifecycle (#139540), and integration with the optimizer

The JIT is still in early stages, but it's already generating complex debugging work. JIT executors not being properly freed (#139540), better uop coverage (#131798, 29 comments), and interactions with the peephole optimizer (#126835) are all active areas.

Subinterpreters

• 
  77 issues carry the topic-subinterpreters label


• Led by Eric Snow (96 issues filed, 291 comments), the most prolific reporter on subinterpreter work

Subinterpreters represent Python's answer to true parallelism without shared state. The issues here tend to be deep interpreter internals: crashes when importing modules in parallel (#90228, 60 comments), GIL state API compatibility (#59956, 57 comments), and custom environments in subinterpreters (#126977).

Together, these three initiatives account for over 200 labeled issues and are generating some of the most intense discussion in the tracker. They represent CPython's attempt to solve its three biggest historical limitations -- the GIL, interpreted performance, and true parallelism -- simultaneously. No other period in CPython's history has seen this many fundamental architectural changes happening in parallel.

The risk isn't that any one of these initiatives will fail. It's that their combined bug surface overwhelms the maintainers' capacity to debug and stabilize. Every new thread-safety bug in free-threading, every JIT executor lifecycle issue, every subinterpreter crash -- they all land in the same tracker, reviewed by many of the same people, competing for the same finite attention.

The Ancient Backlog

At the very bottom of the issue tracker, there are bugs from before Gmail existed.

179 issues from 2003-2009 are still open. They cluster around IDLE, Tkinter, and the email module -- subsystems that receive less active maintenance today. Some of these issues may no longer be relevant. Others may have been fixed incidentally over two decades of development. A few are probably still broken.

The ancient backlog tells us something important about open-source maintenance. These aren't critical bugs -- if they were, they'd have been fixed. They're the kind of edge cases and minor irritants that aren't important enough to prioritize but aren't wrong enough to close. They accumulate quietly, year after year, because no one has both the expertise and the motivation to either fix them or declare them won't-fix.

There's 916 issues from 2010-2014 still open. 1,621 from 2015-2019. The half-life of a CPython issue is long.

Some of these ancient issues are occasionally rediscovered. 191 issues have comments explicitly stating the problem is "still relevant" or "still happening" -- someone circled back months or years later to confirm the bug persists. _abc._abc_subclasscheck has poor performance and a suspected memory leak (#92810), confirmed still relevant in March 2025. Multiprocessing's Queue deadlock (#85880) was confirmed still active in 2023. Cross-module dataclass inheritance breaking get_type_hints (#89687) was confirmed in July 2025. These aren't theoretical problems -- they're bugs that people keep hitting, year after year.

The Velocity Problem

Comment activity on still-open issues tells the story of an accelerating project:

Comment volume on open issues nearly doubled from 2024 to 2025: 4,692 to 7,243 (+54%). This isn't just people talking more -- it reflects more issues, more complex issues, and more active development on major features (free-threading, JIT, 3.14/3.15 release work).

The monthly data for 2025 shows sustained intensity:

October 2025 was the single busiest month in the tracker's history for open-issue discussion, with 817 comments. There's no quiet season anymore.

To put this in perspective: the entire year of 2010 saw 755 comments on issues that remain open today. October 2025 alone exceeded that. A single month in 2025 generated more discussion than an entire year did fifteen years ago. The project's communication footprint has grown by an order of magnitude, and the people reading and responding to all of it are largely the same group they were a decade ago -- just with more on their plates.

What This Means

The data paints a portrait of a project at an inflection point. Here's the synthesis:

CPython's development velocity has never been higher. The number of issues filed, comments written, and features being developed simultaneously (free-threading, JIT, subinterpreters, new platform support) is at an all-time high. Comment volume grew 54% year-over-year. 2025 saw the most new issues in any single year.

The backlog is growing faster than it's being resolved. 1,087 new issues remained open from 2025 alone. The total of 7,154 open issues will likely exceed 8,000 by end of 2026 at current rates. This isn't a sign of poor quality -- it's a sign that CPython's scope and ambition are outpacing its capacity to close the loop on everything.

Maintainers are stretched thin. The top 5 commenters write 15% of all discussion. Serhiy Storchaka alone touches 13% of all open issues. Terry Reedy is the primary voice on 708 issues. The project's institutional knowledge and review capacity is concentrated in a remarkably small number of people. The bus factor is real.

There are clear onboarding opportunities. 1,104 documentation issues. 116 issues labeled easy. 349 issues the community thinks should be closed. 760 issues with zero comments that need at minimum a triage response. New contributors don't need to fix compiler internals to make a meaningful impact.

The "boring" modules need love. IDLE (289 issues), multiprocessing (279 issues), and email (253 issues) are the quiet maintenance backlog. They're not as exciting as the JIT compiler, but they're used by millions of people and they're accumulating bugs faster than anyone is fixing them. 649 issues have workarounds posted -- real bugs that real users are routing around.

Free-threading will change everything. With 99 issues already mentioning it and threading discussions accounting for 13.4% of comment text, the removal of the GIL is creating an entirely new class of bugs. This will likely be the dominant theme of CPython development over the next several years. The 436 issues already tagged with threading concerns are just the beginning.

The version transition creates sustained pressure. Issues mention Python 3.8-3.10 most frequently (over 1,000 mentions each), reflecting bugs that span EOL versions people are still running. Meanwhile, 3.13 (394 labeled issues), 3.14 (270), and 3.15 (203) are actively accumulating new reports. CPython doesn't just maintain one version -- it maintains the entire trailing edge of a language used by millions.

None of this is a crisis. CPython remains one of the best-maintained open-source projects in the world. A six-minute median response time is extraordinary. 64% of issues getting a comment within an hour is extraordinary. The breadth and depth of technical discussion happening in these 42,089 comments reflects a healthy, rigorous community.

But the data suggests the project is approaching a point where the gap between what CPython is trying to do and the people available to do it becomes harder to bridge. The answer isn't to do less. It's to find ways to bring more people in, to triage more aggressively, and to be honest about what the backlog tells us.

The issues are all there, in the open, for anyone to read. 7,154 of them and counting. And every one of them is an invitation -- to fix a bug, clarify a doc, triage a report, or just confirm that yes, this problem still exists and someone cares about it.

Appendix: Data and Methodology

Repository

All scripts, analysis results, and methodology details are available at the project repository.

What Was Collected

How It Was Analyzed

• 
  Topic detection: Keyword and regex matching across titles, bodies, and comment text


• 
  Sentiment patterns: Regex-based detection of agreement, disagreement, workarounds, reproduction attempts, and close suggestions


• 
  Response time: Calculated from issue created_at to first comment created_at
  


• 
  Core developer identification: Cross-referenced against the list of CPython core developers with commit access


• 
  Temporal analysis: Comments and issues bucketed by year, month, and response-time windows

Limitations

• Issues migrated from bugs.python.org may have incomplete comment histories


• Comment body truncation at 2,000 characters may miss context in very long comments


• Keyword-based topic detection has inherent false-positive and false-negative rates


• "Core developer" classification is based on known handles and may miss some contributors


• The analysis is a snapshot from February 11, 2026; the tracker changes daily

Scripts

Data collected February 11, 2026. All issue numbers link to the CPython GitHub repository. Analysis and scripts available for verification and reuse.

SecRule REQUEST_URI "@rx ..." "id:1001,phase:1,deny,status:403"

find /var/www -type f -name "*.php" -mmin -120

ss -tunp | grep -E ":(4444|1337|8080|9001)"

apt update && apt --only-upgrade install <pkg>

title: Detect Exploitation - I Analyzed Every Open Issue in CPython. Here's What I Found.
id: c50dc0e8-1178-466d-a4cd-8875adc1e45a
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-27
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access

rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-27"
        description = "YARA Signature for "
    strings:
        $str = "I Analyzed Every Open Issue in" ascii wide
    condition:
        any of them
}

index=security sourcetype IN ("cisco:asa", "pan:traffic", "zeek_conn", "suricata", "WinEventLog:Security")
("I Analyzed Every Open Issue in CPython H")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, dest_host, signature
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count

message: "*I Analyzed Every Open Issue in CPython H*"

CommonSecurityLog
| where Message has "I Analyzed Every Open Issue in CPython H"
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Activity
| extend DetectionRule = "iShareStuff-CTI-Compiled"
| sort by EventCount desc