Scenario wins: Mantic (6) lewinke-thinking-bot (6) pgodzinbot (5) SynapseSeer (2) smingers-bot (2)
Forecast: Probability distribution:
Key facts from the team: (a) as of 2026-04-22, the Fedora wheels readiness tracker shows all 20 named packages as not yet publishing Python 3.15-compatible wheels (so the count is effectively 0 today); (b) the resolution deadline (2026-08-04 22:00 UTC) coincides with Python 3.15.0rc1, i.e., before the final 3.15.0 release; (c) overall tracker-level readiness can be high because many top packages are pure-Python/abi3, but this particular list is heavily concentrated in the “hard remaining” set (large C/C++/Fortran/Rust extension stacks and tightly-coupled scientific packages).
This creates two opposing forces:
Netting this out, I expect a majority of the “smaller/medium” packages to be ready by Aug 4, but a meaningful subset of the largest stacks to still be unready at that exact time, producing a median in the low teens with a wide, asymmetric uncertainty range (small chance of near-zero if everyone waits until after rc1; smaller-but-nontrivial chance of mid-to-high teens if multiple big stacks ship by late July).
An amateur forecast is likely to over-anchor on one salient statistic: either (i) “88% of top packages are ready already, so almost all 20 will be ready” (overly optimistic, ignoring that these 20 appear to be concentrated among the hard, still-red packages), or (ii) “all 20 are red today, so almost none will be ready” (overly pessimistic, ignoring the typical acceleration during beta/RC and that several packages here are relatively quick to rebuild). My forecast explicitly conditions on the deadline coinciding with 3.15.0rc1 (a structural reason for heavyweight stacks to lag) while still allowing substantial upside from coordinated ecosystem pushes (e.g., Fedora-driven). I’m moderately confident this is better calibrated than either extreme anchor, though uncertainty remains high due to correlated dependencies (especially within the scientific stack).
Forecast rationale (numeric):
— Iteration 1 — The forecasts share a common starting point: all 20 packages are currently not ready, so the outcome hinges on how quickly maintainers can cut new releases with Python 3.15-compatible wheels before the August 4, 2026 deadline. Both rationales treat the problem as a package-by-package adoption question shaped by release cadence, build complexity, and the timing of the 3.15 pre-release cycle.
A major point of agreement is that packages with compiled extensions vary sharply in readiness. Smaller or more agile projects are expected to adapt earlier, while larger, dependency-heavy scientific packages tend to lag until late beta or RC stages. The numerical/scientific stack is especially important because delays can be correlated: if one key project slips, related projects may also be delayed.
Another shared factor is that Python 3.15 may be easier to target than a full ABI transition because GIL-only cp315 wheels are sufficient, which should improve the odds of near-term compatibility. Even so, both forecasts keep wide uncertainty bands, reflecting risks such as toolchain issues, policy changes, and synchronized deferrals to the final release cycle.
The main difference is in central tendency: one estimate leans more conservative, expecting about half the set to be ready by the deadline, while the other is more optimistic and places the count in the mid-teens. Overall, the collective reasoning points to a moderate-to-high number of packages publishing compatible wheels, with substantial uncertainty but a plausible range centered in the low-to-mid teens.
— Iteration 2 — The forecasts share a similar overall logic: with roughly three months remaining before the cutoff, there is still enough time for many packages to publish Python 3.15 wheels, but the outcome is constrained by build complexity and ecosystem dependencies.
Key factors driving the reasoning:
Areas of agreement:
Main differences:
Overall, the collective reasoning points to partial but not complete adoption by the deadline, with the largest risks coming from heavy compiled dependencies and ecosystem-wide build/readiness delays.
— Iteration 3 — Across the forecasts, the reasoning centers on a few common themes:
Current readiness matters, but is not decisive. One rationale starts from the fact that a large share of the named packages are still unready on the current tracker snapshot, suggesting the set is skewed toward harder, slower-moving projects. The other treats the present ecosystem as broadly healthy overall, using ecosystem-wide readiness as a positive signal rather than the package list alone.
The deadline is strategically important. Both forecasts emphasize that August 4, 2026 coincides with Python 3.15.0rc1, which is a natural point for maintainers to finalize and publish wheels. This creates a “catch-up window” in the weeks leading up to the cutoff.
Package complexity is the main source of risk. Compiled packages, large build matrices, and the scientific stack are viewed as the most likely laggards. Correlated delays among packages like NumPy/SciPy/Pandas/scikit-learn are treated as especially important because one build problem can affect multiple projects at once.
Historical release behavior is a key predictor. One model relies on prior wheel-shipping patterns for new Python minors, while the other implicitly assumes that most projects will follow the usual beta/RC release rhythm and ship compatible wheels in time.
The estimates differ mainly in how much catch-up is expected. One forecast is more conservative, centering around 14 ready packages because the starting point looks unfavorable and some projects may miss the rc1-day timing. The other is more optimistic, centering around 17 ready packages, based on broad ecosystem readiness and the expectation that many remaining packages will finish during the beta/RC period.
Overall, the shared logic is: most packages will likely be ready by the deadline, but the final count will be determined by whether the slower compiled projects manage to converge during the Python 3.15 release-candidate window.
Agent Forecast (discrete, confidence: low)
Base Rate: For Python 3.14, the fastest major binary-extension package (NumPy) published cp314 wheels July 24, 2025 — 2 days after RC1. However, 88.6% of the broader Python 3.15 ecosystem already has wheels by April 22, 2026 (alpha phase), suggesting significantly faster tooling adoption than in the 3.14 cycle. The 20 tracked packages represent the hardest ~11.4% of the ecosystem.
Initial Reasoning:
Key Uncertainties:
Evidence Sources (9):
Grounding Facts (passed to reviewers):
Draft: 0: 32.0%, 1: 22.0%, 2: 17.0%, 3: 11.0%, 4: 7.0%
Reviewer Panel:
Reviewer (reasoning)
The draft reasoning leans too heavily on C-extension historical lags and treats all 20 packages as if they require full ABI stabilization before any wheel can appear. It overlooks that pure-Python wheels (e.g. pyyaml), stable-ABI (‘abi3’) wheels, and Rust-based packages often roll out new-version wheels well before RC1. By ignoring these faster paths to compatibility, the forecast overstates the chance of zero releases.
Objections:
Reviewer (calibration)
The draft forecast primarily relies on the ‘wait for RC1’ stance for binary extension packages and historical delays for Python 3.14, heavily skewing its probability towards a near-zero outcome. This perspective largely overlooks the significant fact that 88.6% of the overall Python 3.15 ecosystem already has compatible wheels by April 22, 2026. This high overall readiness suggests that a considerable number of maintainers do not strictly adhere to waiting for RC1, undermining the core assumption applied to all 20 packages.
Objections:
Reviewer (fact-checker)
1 unsupported claim(s). Verdict: minor_issues
Unsupported claims:
Adjustment Rationale:
Shifted probability mass away from 0 (0.32→0.18) and toward the 3-6 range after reviewers correctly identified that (1) the 88.6% overall ecosystem readiness during alpha implies build tooling has added cp315 support earlier than for 3.14, increasing the chance of beta-period experimental wheels, (2) Rust/PyO3 packages (pydantic-core, orjson, rpds-py) have more automated pipelines via maturin that could enable faster publication, and (3) abi3 stable-ABI wheels provide a path for some packages to ship before RC1. However, I maintained a below-median expectation (~3 packages) because the 20 tracked packages are specifically the ~11.4% laggards in the ecosystem — the hardest cases — and the historical pattern of major binary-extension packages waiting for RC1 ABI stability remains the strongest predictor. The tight deadline (RC1 day = resolution day) is the binding constraint. Downgraded confidence to ‘low’ given the inability to verify whether any of the 20 packages have already started cp315 CI integration or published experimental wheels.
forecast_sdk | 636.1s | research $0.8679 + reviewers $0.0084 + reconcile $0.2621 = $1.1383
Agent Forecast (discrete, confidence: medium)
Base Rate: As of April 2026, 0/20 packages in this cohort have published any form of Python 3.15-compatible wheel (cp315, abi3, or py3), per the Fedora tracker. The 88.6% (319/360) ecosystem-wide readiness rate applies exclusively to pure-Python and abi3 packages, not to this C-extension cohort. For Python 3.14: numpy published cp314 wheels on RC1 day (July 24, 2025); most others published weeks-to-months after the October 7, 2025 final release.
Initial Reasoning:
Key Uncertainties:
Evidence Sources (13):
Grounding Facts (passed to reviewers):
Draft: 5: 18.0%, 4: 15.5%, 6: 15.5%, 7: 11.5%, 3: 9.5%
Reviewer Panel:
Reviewer (reasoning)
The draft forecast heavily relies on Python 3.14 release patterns while ignoring that as of April 8, 2026, 88.6% of 360 tracked packages already have 3.15 wheels—even four months before RC1. It also fails to account for ‘py3’ and ‘abi3’ wheels which automatically cover new minor versions and are widely used in these top-20 packages. Consequently, the forecast underestimates the likely high adoption rate by August 4, 2026.
Objections:
Reviewer (calibration)
The draft forecast significantly underweights the robust ecosystem-wide readiness for Python 3.15 indicated by the Fedora Wheels tracker, which shows nearly 90% of packages already having compatible wheels by April 2026. While specific historical delays for Python 3.14 are noted for some packages, the fact that such a high percentage of a broader set of packages are already ready significantly weakens the argument that most of these 20 critical packages will wait until or after the final release. The list comprises highly maintained and fundamental libraries, which are generally ahead of the curve, not behind.
Objections:
Reviewer (fact-checker)
6 unsupported claim(s). Verdict: minor_issues
Unsupported claims:
Adjustment Rationale:
Follow-up search of the Fedora Python 3.15 Wheels Readiness tracker (status.fedoralovespython.org/wheels_py315/) decisively refuted the reviewers’ primary objection. All three reviewers argued that the 88.6% (319/360) readiness rate implied my forecast was too pessimistic. However, the tracker data reveals that ALL 20 packages in our cohort are marked ✗ (not ready) — they fall in the 11.4% that require cp315-specific compiled wheels. The 88.6% green packages are pure Python (py3-none-any) or stable ABI (abi3) packages that automatically work on any Python version. This tracker also refuted my own assumption that markupsafe uses abi3 wheels — it doesn’t, so I lowered its probability from 25% to 18%. The overall distribution shifts negligibly leftward (mode stays at 5, EV ~5.3 vs draft’s ~5.4). The confirmed 0/20 readiness as of April 2026 strongly validates the RC1-centric timing dynamic: these C-extension packages cannot publish cp315 wheels until the ABI stabilizes at RC1 (August 4), and historically most wait until the final release. Only numpy (published on RC1 day for 3.14) and the Rust/maturin packages (pydantic-core, orjson, rpds-py) have strong odds of publishing on the RC1 day itself.
forecast_sdk | 1083.7s | research $1.8978 + reviewers $0.0137 + reconcile $0.4834 = $2.3950
Extracted Percentile Values: {0.1: 2.2, 1.0: 3.8, 5.0: 6.2, 10.0: 7.4, 15.0: 8.3, 20.0: 9.0, 25.0: 9.8, 30.0: 10.4, 35.0: 10.9, 40.0: 11.4, 45.0: 11.8, 46.0: 11.9, 47.0: 12.0, 48.0: 12.1, 49.0: 12.2, 50.0: 12.3, 51.0: 12.4, 52.0: 12.5, 53.0: 12.6, 54.0: 12.7, 55.0: 12.8, 60.0: 13.2, 65.0: 13.7, 70.0: 14.1, 75.0: 14.6, 80.0: 15.0, 85.0: 15.6, 90.0: 16.2, 95.0: 17.0, 99.0: 18.0, 99.9: 18.8}
Model’s Answer: My baseline starts from the tracker itself, because it is the exact resolution source and very recent. As of April 22, all twenty named packages are still red, so the current realized count is zero. But there are still about three and a half months left, and that period covers the part of the Python release cycle when wheel support usually accelerates sharply: late beta into RC, once the ABI is more stable and maintainers are willing to publish official wheels rather than forcing source builds.
Step one is separating these packages into groups rather than treating them as twenty independent coin flips.
The scientific stack is the biggest cluster: numpy, scipy, pandas, scikit-learn, matplotlib, pillow, and to some extent pyarrow. These are highly correlated. If NumPy lands 3.15 support on the usual sort of schedule, several downstream packages can follow fairly quickly; if NumPy or SciPy slips, a whole block of packages can miss the deadline together. That correlation raises tail risk on both sides.
There is a middle group of widely used extension packages that are simpler and usually quicker to add support once the release cycle matures: cffi, pyyaml, pydantic-core, markupsafe, rpds-py, regex, lxml, and orjson. I expect most of this group to make it by early August, but not all with certainty, because these packages are on the tracker precisely because their latest releases do not already have an abi3 or py3 escape hatch.
Then there are the lower-probability laggards: grpcio, grpcio-tools, greenlet, uvloop, and somewhat aiohttp. The research is especially bearish on grpcio and grpcio-tools, where public discussion points to an October target more than an early-August target. Greenlet and uvloop also tend to be more sensitive to CPython internals and platform build friction.
The strongest single piece of positive evidence is timing. The August 4 deadline is not “far before” Python 3.15 stabilization; it is roughly in the RC neighborhood. That makes a count in the low teens much more plausible than a count near zero. The strongest negative evidence is selection effect: these twenty are not a random sample of packages, they are a handpicked group of the hard remaining cases. The fact that 88.6 percent of the top 360 are already ready mostly tells me the easy packages are gone; it does not imply these holdouts will all flip quickly.
My rough package-level expectations sum to about twelve to thirteen ready packages by the deadline, with meaningful common-cause uncertainty. I am pulling the center slightly below the simple independent sum because of deadline risk: some maintainers aim for “before 3.15 final” or “around RC” rather than specifically “by August 4, 22:00 UTC,” and this question cares about that exact cut.
The assumptions that matter most are the release-timing assumption, the NumPy-led cascade assumption, and the grpc laggard assumption.
The release-timing assumption is that Python 3.15 reaches the expected late-beta/RC stage on schedule and that maintainers treat that as sufficiently stable to publish wheels. I think there is about a 20 percent chance this assumption is wrong enough to materially lower counts, through either schedule slippage or maintainers waiting for a later milestone.
The NumPy-led cascade assumption is that NumPy support arrives in time for scipy, pandas, matplotlib, and scikit-learn to follow by the deadline. I think there is about a 30 percent chance this is wrong or only partially true. If it fails, the total can easily drop by three to five packages at once.
The grpc laggard assumption is that grpcio and grpcio-tools remain behind by August 4. I think there is about a 35 percent chance this assumption is wrong, meaning one or both surprise to the upside. That matters because the upper tail is mostly driven by “almost everyone except maybe grpc.”
A low outcome would come from a slower-than-expected ecosystem transition around beta/RC, especially if NumPy/SciPy and a few build-tooling dependencies slip together. In that world, only the simpler extension packages and a subset of the middle group make it, and the result lands around seven to nine. I put the chance of a distinctly low outcome, roughly eight or fewer, at around 15 percent.
A high outcome would come from the opposite pattern: the release schedule stays on track, NumPy lands on time, downstream scientific packages issue coordinated releases, Rust-extension packages update promptly, and only grpcio or one other stubborn package misses. In that world the count gets into the mid-to-high teens. I put the chance of a distinctly high outcome, roughly sixteen or more, at around 12 to 15 percent.
So my distribution is centered in the low teens, with a fairly wide spread because of correlation and because the exact deadline sits near an ecosystem transition point rather than long after it. My median is a bit above twelve, and my ninety percent interval is roughly seven to seventeen.
Percentile .1: 2.2 Percentile 1: 3.8 Percentile 5: 6.2 Percentile 10: 7.4 Percentile 15: 8.3 Percentile 20: 9.0 Percentile 25: 9.8 Percentile 30: 10.4 Percentile 35: 10.9 Percentile 40: 11.4 Percentile 45: 11.8 Percentile 46: 11.9 Percentile 47: 12.0 Percentile 48: 12.1 Percentile 49: 12.2 Percentile 50: 12.3 Percentile 51: 12.4 Percentile 52: 12.5 Percentile 53: 12.6 Percentile 54: 12.7 Percentile 55: 12.8 Percentile 60: 13.2 Percentile 65: 13.7 Percentile 70: 14.1 Percentile 75: 14.6 Percentile 80: 15.0 Percentile 85: 15.6 Percentile 90: 16.2 Percentile 95: 17.0 Percentile 99: 18.0 Percentile 99.9: 18.8
Resolution of Disagreements:
1. MarkupSafe abi3 status — RESOLVED. The targeted research clearly resolves this. The maintainer (davidism) explicitly stated on GitHub issue #411: “MarkupSafe doesn’t use the limited API, so it doesn’t produce abi3 wheels. It must be built for each version of Python.” The PyPI file listings for MarkupSafe 3.0.2 confirm this — all wheels are version-specific (cp310, cp313), with no abi3 wheels present. This means MarkupSafe is NOT already ready and must publish a new release with cp315 wheels. Forecaster_5’s claim of “Hard floor = 2 already effectively satisfied (orjson, MarkupSafe)” is incorrect. The floor is 1 (orjson only). This supports the more cautious forecasters (1, 2) who treated markupsafe as uncertain (60-70%).
2. cffi abi3 status — PARTIALLY RESOLVED. The PyPI page for cffi 2.0.0 shows version-specific wheels (cp314, cp314t), not abi3 wheels. The file listing is truncated but shows cpXXX-tagged wheels, not abi3. This suggests cffi also does NOT ship abi3 wheels and would need a new release with cp315 wheels. This further supports the view that the floor is just 1 package (orjson).
3. Historical base rate at RC+7 — NOT DIRECTLY RESOLVED but contextualized. The Python 3.14 ecosystem stats from discuss.python.org show that on release day (October 2025), 347 packages out of 15,000 had version-specific wheels for 3.14. The article notes “Python 3.14 was the best Python release ever” for day-1 readiness. However, this is for the final release, not RC+7. The research doesn’t directly verify forecaster_5’s claim of “5-7/20 at RC+7” but the general ecosystem data suggests adoption was improving. The claim remains unverified but plausible.
4. NumPy/scipy timing — INCONCLUSIVE. The search for “numpy scipy Python 3.15 CI support 2026” returned no results. The Medium article mentions “major libraries like NumPy, scikit-learn, Django, and Textual have already announced compatibility fixes” for 3.14 RC1, suggesting these packages do engage during the RC phase, but this doesn’t tell us about 3.15 timing specifically.
Updated Analysis:
The key finding is that both markupsafe and cffi do NOT ship abi3 wheels — they require version-specific builds. This lowers the effective floor from 2 to 1 (only orjson confirmed ready). This shifts the distribution slightly downward, particularly affecting the lower percentiles.
However, the broader ecosystem data is somewhat encouraging: Python 3.14 had significantly better day-1 readiness than 3.13 (347 vs 178 packages with version-specific wheels), suggesting an improving trend. The 3.15 cycle could benefit from this momentum.
The structural constraint remains dominant: RC1 is July 28, only 7 days before the August 4 deadline. Packages needing cp315 wheels (which now includes markupsafe and cffi, not just the heavy scientific packages) face a very tight window.
Given the research:
The weighted average should be adjusted slightly downward, particularly at the lower end, to reflect the confirmed non-abi3 status of markupsafe and cffi. Forecaster_5’s lower estimates gain some credibility on the floor question, but their overall central tendency still seems somewhat too pessimistic given the improving ecosystem trends. The majority view (median ~10-11) should be nudged down modestly to ~9-10.
Confidence: MEDIUM
Percentile 10: 3 Percentile 20: 5 Percentile 40: 8 Percentile 60: 10 Percentile 80: 14 Percentile 90: 16
Our analysis focused on the synchronization between the Python 3.15 release cycle and the development patterns of high-profile, compiled packages. As of April 2026, none of the 20 target packages had published Python 3.15 wheels, which we identified as expected behavior given that the Python 3.15 ABI (Application Binary Interface) only stabilizes during the Beta phase.
The crux of our reasoning relies on the narrow three-month window between Beta 1 in May and the August 4 deadline, which coincides exactly with the scheduled release of Release Candidate 1 (RC1). While the broader Python ecosystem shows high readiness, this specific cohort consists of complex “laggards”—packages involving C-extensions, Rust, or heavy scientific stacks like NumPy and SciPy. These projects often wait for upstream dependencies to stabilize before publishing their own wheels.
We considered the high likelihood of a “logjam” effect, where a delay in a foundational package or a shared build tool (like pyo3) could cause several downstream packages to miss the RC1 window. Our prediction reflects a high but incomplete adoption rate, accounting for both the efficiency of modern automated CI/CD pipelines and the historical tendency for a few technically challenging packages to slip past the first release candidate.