PEP 836, the proposal for a supported CPython just-in-time compiler, is now marked Withdrawn. For a team running Python services, the useful question is which runtime and build the application actually uses. A proposal’s withdrawal and a change to an installed release are different events. As of October 28, 2026, the primary records reviewed here confirm the withdrawal and the council’s conditions for continuing development; they do not by themselves prove a removal commit has shipped in every Python release.
What changed in the proposal
Savannah Ostrowski announced the withdrawal on October 19, explaining that the authors lacked the capacity to carry the current proposal forward. She also said they intended to make the reference implementation available for others to explore. That leaves room for future work, without providing a delivery commitment.
Read the authors’ withdrawal announcement
The Steering Council’s June announcement had paused new JIT features and performance work in CPython’s main branch pending an accepted Standards Track PEP, while allowing bug and security fixes. It set a six-month window: without an accepted proposal, JIT code would need to leave main and development continue elsewhere. This is a development-governance condition, rather than an instruction to uninstall a production interpreter.
Read the Steering Council’s conditions
Read version-specific documentation
PEP 836 describes the Python 3.15 JIT as experimental and opt-in. It says official Windows and macOS binaries include it disabled by default. Its proposed performance milestones were goals for future work, not a guarantee for an application. Because the proposal is withdrawn, those milestones should not become assumptions in a capacity plan.
Check PEP 836’s status and scope
Python 3.13’s documentation shows why build details matter: its experimental JIT configuration can disable the pipeline, enable JIT execution, build it disabled by default, or use a Tier 2 interpreter. These are documented choices for that release. Apply the documentation matching your own interpreter and distributor when checking another version.
See Python 3.13’s experimental JIT build options
Create a runtime record before changing anything
A practical inventory should identify the Python implementation, full version, executable path, operating system, package source and container or environment identifier. Add the build configuration and relevant launch settings where your deployment system records them. Keep separate entries for web workers, background jobs and scheduled tasks; they may use different environments even when they share a repository.
For example, imagine a checkout API using a distributor’s ordinary build while an overnight reporting worker uses a custom JIT-enabled build. A headline about CPython’s main branch does not establish the same operational impact for both. The API owner may need only to track future release notes. The reporting owner has a concrete reason to preserve the current build recipe and test the next candidate interpreter.
Measure the workload you intend to deploy
Treat any runtime change as a controlled trial. Hold application code, dependencies, test data and resource limits constant. Include startup, warm-up and steady-state behavior, then compare response time, throughput, memory use and error rates. Choose acceptance limits before seeing the results. A faster small benchmark is insufficient evidence for a service with different bottlenecks.
Check the operational tools as well: can the team still obtain useful profiles, inspect failures and run its normal tests? Keep a working rollback artifact and a record of the candidate build. These are recommended evaluation steps, not reported findings from a benchmark conducted for this article.
What teams in the USA and India can do now
Assign one owner to monitor the runtime’s release notes and distributor guidance. Give application owners a short record of their current build and the conditions that would trigger a trial. Teams sharing deployments across US and Indian offices can use the same acceptance criteria while measuring each actual environment. There is no basis here for a country-specific performance promise or an emergency migration deadline.