Python 3.15 Gets a Surprise RC3 and Other Python News for October 2026

The Packaging Council Is Elected

Voting in the elections we flagged last month closed on September 15, and on September 17 the PSF announced the first-ever Python Packaging Council. Brett Cannon and Pradyun Gedam won two-year terms. Donald Stufft, Henry Schreiner, and Ralf Gommers won one-year terms. Voters cast 541 ballots. The PSF Board election finished the same day, seating Elaine Wong, Laís Carvalho, Ee Durbin, and Georgi Ker. It drew 670 ballots.

The new council already has two items on its desk. Both are draft PEPs that deal with virtual environments:

• PEP 832 standardizes how tools discover a project’s environment.
• PEP 838 standardizes a python-version field in pyvenv.cfg. Tools already record the version there using different keys and formats. The new field holds only the major and minor version numbers, so it doesn’t go stale after a patch upgrade.

Both sit between the core interpreter and the packaging tools, so who gets to decide? Brett Cannon put that question to the Steering Council in August. On September 10, the Steering Council answered that the two PEPs fall within the responsibility it shares with the Packaging Council under PEP 772. The two councils would reach a joint decision once the Packaging Council was seated, which happened a week later.

PEP 832 itself changed in the meantime. On September 8, Cannon reverted it to its earlier design with a .venv redirect file. That leaves a nice bit of irony: Cannon, the PEP’s author, now sits on one of the two councils that will rule on it. Overlapping roles like this are normal in a small community, and the recusal conversation will be worth watching.

The other institutional thread runs through the python/prebuilt-cpython repository, which has hosted planning for official prebuilt, relocatable CPython builds since October 2025. Today, the builds that uv downloads when you ask for a Python version come from Astral’s python-build-standalone project.

An official alternative under the python organization would make the ecosystem less dependent on any single company, a comforting prospect after the acquisition news.

Astral, for its part, kept shipping. A uv pull request merged on August 31 deduplicates identical files across the wheel cache by hard-linking them, which reduced the PR author’s cache size by about 10 percent. The feature is hardly glamorous, but your disk will appreciate it.

PyPI Gets Stricter About Its Own Numbers

PyPI had three stories this month, and all of them are about knowing what the index is actually doing.

First, download counting got stricter. Since August 24, a request counts as a download only if it fetches a .whl, .tar.gz, or .zip file. Metadata-only requests from installers, which made up about 40 percent of the old traffic, no longer count. If you maintain a package and your downloads dropped sharply around August 24, then the new counting rule is the probable cause.

Older numbers weren’t filtered after the fact, so filter both periods the same way before you compare them. PyPI itself warns that download counts don’t measure users or popularity.

Second, PyPI published a postmortem for intermittent file-hosting errors that ran from August 15 to 28. The mix of 502 and 503 errors on files.pythonhosted.org came from a partially rolled-back canary deployment at Fastly combined with several configuration bugs on PyPI’s side. If your CI pipeline failed randomly in the second half of August, then you now have your explanation.

Third, Brett Cannon wrote up what’s missing for reproducible builds on PyPI. Wheels can already record their build tools in an SBOM under PEP 770.

What’s still missing is a standard way for a source distribution to say where it came from, a way for it to carry an SBOM, and a way to use PyPI to publish independent verification that a wheel matches its source. He sketches fixes for all three, including a new source distribution format and trusted verifiers that would vouch for reproducibility through the index API.

Put together, these stories show where packaging governance is heading. The new council inherits an index that’s getting better at measuring itself, which will help the council make decisions based on those numbers.

EVE Online Starts Its Move to Python 3

Fenris Creations, formerly CCP Games, announced that EVE Online has begun migrating to Python 3. In case you’ve never heard of it, EVE is a spaceship MMO that launched in 2003 and has been running on Stackless Python ever since. It moved to Stackless 2.7 in 2010 and stayed there, which means the game has outlived Python 2 itself by several years.

The codebase is 2.4 million lines of Python. So far, only the first stage has shipped: code that’s Python 3–ready but still runs on 2.7. Fenris gives no completion date and calls this the beginning of a long road, which is probably the most accurate migration estimate anyone has ever published. If you put off your own Python 3 migration until 2019, then you can feel a little better now.

EVE’s migration is also a reminder of how far Python reaches. A game with hundreds of thousands of players has been running its logic in Python for over two decades, and its developers are still choosing to invest in the language rather than leave it.

Django’s Survey Explains the Annual Releases

The State of Django 2026 survey from JetBrains and the Django Software Foundation collected nearly 3,500 responses from more than 40 countries. Its subtitle, Boring Is So Back, sums up the results. PostgreSQL has held steady at 76 to 79 percent of respondents for five years, and 43 percent are already on Django 6.0.

That second number provides context for Django’s move to annual releases last month. Starting in January 2028, every feature release will get three years of support, so the long-term support (LTS) label goes away. Django 6.2 LTS is still scheduled for April 2027. Given that 43 percent of survey respondents had already moved to Django 6.0 before 6.1 came out, three years of support for every release matches how people actually upgrade.

The survey also shows that 58 percent of respondents who use AI coding tools rely on them daily, that uv has reached 43 percent adoption, and that Ruff is the most popular code-quality tool. Christopher Bailey and Christopher Trudeau dug into the results on episode 311 of the podcast. If you’re starting a Django project today, then the survey gives a good picture of what everyone else is using.

Your Sets Can Be Quadratic

One of the most-read links in PyCoder’s Weekly this month was Daniel Lemire’s demonstration that Python sets and dictionaries can have quadratic-time performance. The trick relies on how CPython hashes integers, using the Mersenne prime 2⁶¹ − 1 as the modulus on 64-bit builds:

>>> M = 2**61 - 1
>>> hash(M), hash(2 * M), hash(3 * M)
(0, 0, 0)

Every multiple of that prime hashes to zero, so they all start at the same slot in the hash table. CPython resolves collisions by probing other slots, and keys with equal hashes follow the same probe sequence, so each new key has to step past all the ones inserted before it.

In Lemire’s benchmark, inserting a few thousand such multiples into a set turns a constant-time operation into a linear one, and filling the whole set becomes quadratic. The elapsed time roughly quadruples whenever the input doubles, reaching around 45 seconds for 100,000 keys.

You won’t hit this with ordinary data, but you can when an attacker picks your dictionary keys, which is why string hashing has been randomized since Python 3.3. Integers aren’t randomized.

In a nice coincidence, the Python 3.16 docs picked up a new time-complexity reference page covering the Big O costs of list, deque, set, and dict operations. It gives you an official answer to how fast each operation is, including the fine print about average and worst cases that Lemire just demonstrated. If you’d rather see collisions happen up close, then build a hash table yourself or brush up on how dictionaries work.

When str.lower() Is a Security Bug

Seth Larson, the PSF’s Security Developer-in-Residence, explained how str.lower() became a vulnerability behind CVE-2026-17084. The old Internationalizing Domain Names in Applications (IDNA) 2003 standard pins case folding to Unicode 3.2.0, but str.lower() uses whatever Unicode version your interpreter ships with.

For some characters, like the Cherokee letter Ꭰ, the two disagree, so the same domain name can encode to two different Punycode strings.

When two parts of a system disagree about which domain they’re talking about, attackers get a way in. The vulnerability lives in the stringprep module and the standard library’s IDNA 2003 codec, not in everyday str.lower() calls. The CPython fix restores the Unicode 3.2.0 mappings, so upgrade to a Python release that includes it. If you need the newer IDNA 2008 rules, then use the third-party idna package instead of the standard-library codec.

Polars 2.0 Enters Release Candidates

Polars announced 2.0 and published its first release candidate on September 2, and 2.0.0rc2 followed on September 20. The final release is expected in the coming weeks, so this is the time to run your test suite against the release candidate and leave production alone.

The main change is that the streaming engine becomes the default for every LazyFrame query. Polars claims roughly five times the speed, but the new default comes with a catch that will bite somebody. The streaming engine doesn’t keep row order the way the in-memory engine happened to, so code that implicitly relied on the old order can break.

Group-bys are the easiest place to trip up. Polars 1.x never promised the order of .group_by() output unless you passed maintain_order=True, and the new engine makes that caveat much harder to ignore. To try it yourself, install the release candidate into a throwaway environment:

$ uv run --with polars==2.0.0rc2 --prerelease=allow python

Then ask for the order explicitly:

import polars as pl

orders = pl.DataFrame({"customer_id": [2, 1, 2], "amount": [10, 20, 30]})

result = (
    orders.lazy()
    .group_by("customer_id", maintain_order=True)
    .agg(pl.col("amount").sum())
    .collect()
)

If any of your code or tests depend on the order of a .group_by() result, then add maintain_order=True or an explicit sort now. Do the same for joins and unpivots, which 2.0 also no longer keeps in order unless you ask. The release also removes the long-deprecated melt() in favor of unpivot(), rejects lossy type coercions in is_in(), and raises new AttributeRemovedError and ArgumentRemovedError exceptions to point you at removed APIs.

Around the same time, the most-clicked link of the month in PyCoder’s Weekly was Polars’ own guide to pandas-to-Polars migration strategies. It lays out three options: migrate only the slow part, migrate everything by hand, or let an LLM translate your code and repair it against test fixtures until the checks pass. The fact that the third option is presented with a straight face is itself a sign of the times.

For a more hands-on take, Marco Gorelli’s Polars vs SQL differences nobody is talking about explains where the SQL mental model breaks. SQL tables are unordered bags of rows, while Polars DataFrames keep their order.

SQL databases don’t even agree with each other on where nulls go. PostgreSQL puts them last in ascending order and first in descending order, while SQLite puts them first in ascending order. Polars puts them first unless you pass nulls_last=True. None of them is wrong, but if you move queries between SQL and Polars, then you’ll want to know which convention each one follows.

SQLAlchemy 2.1 Goes Final

SQLAlchemy 2.1.0 shipped on September 24, more than three and a half years after 2.0, following release candidates on August 31 and September 8. Mike Bayer describes it as “decidedly not as dramatic” as 2.0, but a few hard changes can still break your setup:

• The greenlet dependency no longer installs by default, so if you use SQLAlchemy’s asyncio support, then install sqlalchemy[asyncio].
• A bare postgresql:// URL now picks the psycopg 3 driver, and oracle:// picks oracledb.
• Python 3.11 is the new minimum version.

On the feature side, a new tstring() construct brings template strings to raw SQL on Python 3.14 and later, binding interpolated values as parameters instead of concatenating them into the SQL string. There’s also long-awaited CREATE VIEW support and a new driver for Microsoft SQL Server.

If your requirements.txt says sqlalchemy with no upper bound, then your next fresh install or upgrade on Python 3.11 or later will pick up 2.1 unless another dependency holds it back. If you use the asyncio support, then change that line to sqlalchemy[asyncio] so that greenlet still gets installed.

Other Releases

A few more releases caught our eye:

• Wagtail 8.0 adds a v3 REST API with read and write support for CMS operations and fixes five security issues in its admin and content APIs. Two members of the Wagtail team are on episode 312 of the podcast.
• Flet 1.0 reached a stable release for building cross-platform desktop, web, and mobile apps in pure Python.
• Poetry 2.5.0 and Flit 4.1.0 landed within days of each other, which fits a month when packaging was the main topic.
• Click 8.5.0, IPython 9.17.0, and a second beta of Pydantic 2.14 rounded out the list.

API Changes That Break Python Code

Here are the changes most likely to turn up as errors in your logs:

1. The OpenAI Assistants API is gone. It shut down on August 26, after we flagged the planned sunset back in March. Any code still calling client.beta.assistants needs to move to the Responses and Conversations APIs.
2. GPT-6 Astra requires the Responses API for tools. The model became generally available on September 3, and tool calling through Chat Completions isn’t supported. It also rejects custom temperature and top_p values and doesn’t return log probabilities.
3. Claude Fable 5.1 and Mythos 5.1 reject some tool_choice values. Both models shipped on September 1 and return a 400 error for tool_choice set to any or tool. The release notes suggest auto combined with strict tool use instead. Strict tool use validates the tool calls the model makes, but auto still lets it skip tools entirely, so if your code depends on a tool call, then check whether the response contains one and handle the plain-text case. Separately, for accounts created on or after August 31, 2026, Claude Fable 5.1 now rejects a replayed thinking block by default if you’ve changed the system prompt, tools, or an earlier message. A beta prefix_mismatch_behavior setting lets you drop the mismatched blocks instead.

None of these changes are unreasonable individually. Taken together, they mean that code you wrote against last year’s APIs may stop working with this year’s models. Keeping model names in configuration and running a small smoke test against every model you plan to switch to is cheaper than debugging in production.

Not everyone is excited about where the new models are heading. Armin Ronacher’s Astra for Coding: Why Are We Doing This Again? argues that GPT-6 Astra is great at finishing tasks and poor at writing code that humans can read, with hard-coded constants and odd workarounds everywhere. He asks whether the models are now being optimized for the wrong goal.

It’s the sharpest counterpoint to the benchmark charts this month, which makes our guide to reviewing AI-generated Python code especially timely.

PyTorch 2.14 Changes Your Gradients

PyTorch 2.14.0 arrived on September 2 with a numerical change that won’t show up as an error. When the input to torch.clamp() or torch.clamp_min() sits exactly on a scalar bound, the gradient is now zero instead of one. You can check it in a throwaway environment on Python 3.14:

$ uv run --python 3.14 --with torch==2.14.0 python

>>> import torch
>>> x = torch.tensor(0.0, requires_grad=True)
>>> torch.clamp_min(x, 0.0).backward()
>>> x.grad
tensor(0.)

In PyTorch 2.13, that last line printed tensor(1.). When the bound is itself a tensor that requires gradients, a tie now splits the gradient evenly between the input and the bound, and fmin() and fmax() follow the same rule. The new behavior is mathematically cleaner, but if you run a training job that relies on exact reproducibility, then pin your version or compare a few runs before you upgrade.

The rest of the ML stack kept moving, too. vLLM 0.29.0 made Model Runner V2 the default and plans to remove V1 in 0.32. Transformers 5.16 replaced its legacy tensor-parallel API with a DTensor-based one, which is a breaking change if you shard models yourself. Then 5.17 added Tencent’s 780-billion-parameter Hy4 preview.

LangChain 1.4.0 added a native langchain.mcp namespace for the Model Context Protocol (MCP), the standard way to connect models and agents to external tools and data. The new namespace builds on August’s MCP rewrite. On OpenAI’s side, the new Agents API entered public beta on September 10, offering a hosted agent harness that handles sessions, context compaction, and recovery for you.

Auto Mode Isn’t a Sandbox

Johann Rehberger showed how to break Claude Code’s auto mode with a poisoned ZIP file. Rehberger succeeded in roughly 60 to 80 percent of the attempts, though the sample was small.

The chain is clever. The attacker’s server pushes Claude to download an archive with curl, and Claude, sensibly distrusting the bundled decoder, writes its own Python decoder instead. The trouble is that it runs that script from inside the extracted directory, where a malicious struct.py shadows the standard-library module. As Rehberger puts it, “Claude does not trust the supplied binary decoder, but it trusts the one it wrote itself.”

Anthropic closed the report as informative, saying that auto mode relies on a best-effort classifier and isn’t a security boundary. That’s a fair answer, and it’s also the lesson. If you let an agent run commands on its own, then isolation and network egress controls are your real protection. The classifier is a convenience. It’s the same moral as last month’s local agent UI bug, one layer further down.