Python's JIT Faces Some Challenges and Other News for July 2026

The Steering Council Puts the JIT on Notice

CPython’s JIT compiler arrived in Python 3.13 as an experimental, off-by-default feature, backed only by the informational PEP 744. In June, the Steering Council announced that this arrangement has run its course.

No new JIT functionality can merge into main until the community approves the project through a standards-track PEP, and that PEP has roughly six months to materialize. If it doesn’t, then the JIT code comes out of main, and development continues somewhere else.

The council’s reasoning is less about the code and more about the commitments around it. Its list of missing pieces includes:

• Committed long-term maintainers
• A security review
• Debugging and out-of-process tooling support
• Defined runtime guarantees

There’s also a process point underneath it all:

…experiments should not be done on the main branch of CPython without a backing PEP. (Source)

The forthcoming PEP will need to spell out who maintains the JIT, how it coexists with CPython features like free threading, profilers, and debuggers, and what counts as success.

That last question is where the community discussion got lively. The current JIT delivers roughly an 8–9 percent geometric-mean speedup on x86-64 Linux and 12–13 percent on AArch64 macOS, but individual benchmarks swing from a 15 percent slowdown to better than a 100 percent speedup.

JIT lead Ken Jin floated a long-term target of around 20 percent, or as he put it, “one-half to one-quarter of PyPy.” For context, contributors measured PyPy at roughly 50 percent faster than CPython 3.15 on macOS, and 80–90 percent faster on x86-64 Linux. Either way, the JIT isn’t there yet, and the council wants a clear-eyed plan before it commits. Side by side, the gap is stark:

Even the JIT’s optimistic 20 percent target barely dents PyPy’s lead, and today’s modest gains leave it well short of either mark.

It’s a healthy moment for the project. Forcing a real maintenance and security story now beats discovering the gaps after the JIT is on by default, so here’s hoping the extra rigor sets the JIT up for a strong future.

Two Maintenance Python Releases and Two Betas

While the JIT debate simmered, the release managers kept the regular cadence going. Python 3.14.6 and 3.13.14 both shipped on June 10, with around 179 and 240 bug fixes, respectively. Neither is a security release, so there’s no fire drill here, just the usual steady stream of fixes that make it worth staying current on the latest bugfix version.

On the pre-release front, Python 3.15.0b2 landed on June 2, the second of four planned betas. The feature set is frozen, so these betas are about stabilizing what’s already in.

Beta 3 followed on June 23, adding around 195 fixes from 86 contributors. Beta 4 is due July 18, the release candidate phase opens August 4, and the final release is expected this fall.

The 3.15 Feature List Locks In

A couple of 3.15-bound proposals crossed the finish line. PEP 798 brings unpacking operations (* and **) into comprehensions, and PEP 800 adds the @typing.disjoint_base decorator for the type system. Both reached Final status as the beta locked their behavior in.

Of the two, PEP 798 is the one you’ll feel day to day. Say that you want to flatten a nested list. That used to take a double loop:

>>> matrix = [[1, 2], [3, 4], [5, 6]]
>>> [value for row in matrix for value in row]
[1, 2, 3, 4, 5, 6]

Now you can unpack the inner iterable right in the comprehension:

>>> [*row for row in matrix]
[1, 2, 3, 4, 5, 6]

The same * and ** work in set, dict, and generator expressions, so {**d for d in dicts} merges a list of dictionaries in one line.

A mid-June housekeeping pass flipped a whole batch of 3.15 PEPs to Final status at once. The headliners include PEP 814’s new built-in frozendict, the long-deferred PEP 686 that finally makes UTF-8 mode the default, PEP 661’s sentinel values, and PEP 831’s frame-pointer support for profiling. With the betas rolling, the 3.15 feature list is essentially settled.

The PSF Opens Its 2026 Plan for Comment

The Python Software Foundation took its planning work a step further, publishing a draft 2026 strategic plan and inviting the community to weigh in through late June. The recurring theme is financial sustainability.

Board chair Jannis Leidel said bluntly that the topic “came up repeatedly” and that the PSF is “stable for now, but we cannot continue on the current path without making meaningful changes.”

The draft lays out a set of organizational and program goals, and the foundation asked the direction-level questions that matter most:

• Are these the right goals?
• Is anything important missing?

Even with the comment window closed, the plan is worth reading if you want to understand the pressures on the organization behind Python itself, the one that funds much of the core development and keeps infrastructure like PyPI online. If your company runs on Python, then it’s a fair prompt to ask whether you’re giving anything back.

That structural pressure is showing up on the calendar, too. The PSF set its 2026 board election dates, with nominations opening July 28 and voting running September 1–15. This year, the vote runs alongside the first-ever election for the new Packaging Council.

Django Hunts for Its First Executive Director

The Django Software Foundation (DSF) is hiring its first-ever Executive Director.

The foundation has always leaned on an all-volunteer board, whose members fund Django Fellows, hand out event grants worldwide, manage memberships, and shoulder the legal and nonprofit work behind the framework. As the DSF’s board president put it:

…for years our board has run the DSF on volunteer time, and we’ve hit the limits of what that can do.

The new position is paid and open to part-time or full-time candidates, covering day-to-day operations, sponsorships, community outreach, and coordination with the Fellows and working groups.

To get it off the ground, a group of Django agencies has pledged seed funding for the role’s first year. Since that covers only the launch, the DSF is raising its annual fundraising goal to sustain the position for the long haul. The board is still finalizing the details and expects to post the job in the coming weeks.

A Core Developer Demystifies Free Threading’s Internals

If the free-threading rollout has felt like a black box, core developer Victor Stinner wrote a couple of posts that open it up:

1. Free Threading internals: reference counting
2. Free Threading internals: deferred reference counting

They’re a clear read on why removing the GIL was so hard in the first place. The short version is that naive thread-safe reference counting is brutally slow. An early experiment made Python about 19 times slower across seven cores because every Py_INCREF turned into a contended atomic operation.

The fix is a stack of techniques:

• Biased reference counting: Each object gets an owning thread that can use cheap, non-atomic updates for the common case.
• Object immortality: Small integers, built-in types, and similar values skip counting entirely (PEP 683).
• Deferred reference counting: Certain objects go to the garbage collector instead of being tracked on every reference.

Together, these techniques keep single-threaded code fast while letting multi-core code actually scale. If you’ve ever wondered what free threading is buying and costing under the hood, those two posts are the ones to read.

Context Rot Erodes Long Agent Sessions

If you’ve watched a coding agent start strong and then slowly lose the plot over a long session, there’s a name for it now: context rot.

A widely shared piece titled Context isolation in coding agent loops made the rounds.

Ticket text, logs, test output, abandoned ideas, and stale assumptions all pile into a single context window until, as the author puts it:

…the context window was a junk drawer. The agent still had all the words, technically. But the structure was gone.

The proposed fix is a matter of architecture rather than a better prompt: split the work across several specialized agents, each with its own clean context, and pass compact summaries between them instead of dragging the entire transcript along.

It’s the same instinct behind treating context as something you deliberately manage, which is exactly the ground that the Context Engineering for Python Codebases tutorial covers.

None of this means long agent sessions are hopeless. The remedy is to curate context instead of letting it accumulate, and a little structure up front buys you far steadier results from the same model.

Delegating Friction Dulls Your Instincts

In a similar vein, Bob Belderbos argued that you shouldn’t delegate the friction of development to AI wholesale. His framing is useful, sorting friction into three kinds:

Hand all of it to a model, and your instincts get rusty. He suggests reviewing AI diffs the way you’d review a junior engineer’s pull request, and even coding solo for a couple of hours a week to keep the muscles working.

The teams getting real value out of these AI tools are the ones who stay in the loop on the parts that matter, not the ones who delegate the most.