Python Wants a std Namespace Because PyPI Owns the Names
Quick answer: At the 2026 Python Language Summit, Pablo Galindo Salgado proposed a top-level std namespace so you could write import std.json. The pitch is about shadowing — a local random.py silently winning over the standard library. The structural reason is that PyPI already owns every good name, which is why the stdlib ships tomllib, graphlib and zoneinfo rather than the obvious words.
Python's standard library lives in a flat namespace shared with every package on PyPI. That has been true since the beginning and mostly works. The 2026 Language Summit session on namespaces, held at EuroPython in Kraków and written up on Python Insider, is the first time a Steering Council member has opened a summit by proposing to change it.
The proposal is small on its face. Add std. Make std.json the same object as json:
>>> import std.json, json
>>> std.json is json
True
Nothing breaks. import json keeps working indefinitely. Galindo put the performance cost at "effectively zero." So the interesting question is not whether this is cheap — it is what problem is actually being solved, because the session surfaced two and they do not have the same weight.
The problem on the slide: shadowing
Put a file called random.py in your project directory. Now import random gets your file, not the standard library, and the next line fails with an AttributeError on a function you are certain exists. Kushal Das called this "a big problem for newcomers," naming math.py as the version he sees most.
This is real and it is genuinely confusing the first time. It is also, for anyone past their first month, a two-second diagnosis. If shadowing were the only motivation, this would be a teaching problem with a linter-shaped solution, not a language change. Any developer tooling that already walks your import graph could flag it.
The problem underneath: the stdlib cannot name things
The second motivation is the one that should interest anyone who maintains a package. Because the stdlib shares a namespace with PyPI, core developers cannot give a new module the name it deserves if PyPI got there first. The result is a decade of defensive naming, and you can read it off the module list.
| Module | The name it wanted | Why not |
|---|---|---|
tomllib | toml | Taken on PyPI |
graphlib | graph | Taken on PyPI |
zoneinfo | timezone | Collision pressure; the write-up calls it an unexpected name |
The -lib suffix is not a convention anyone chose for clarity. It is a workaround that got repeated until it looked like a convention. The summit write-up also raises PyYAML as the illustration of what happens when a popular third-party package is considered for adoption: the name is already in use by the thing you are adopting, so adoption and naming become the same negotiation.
That is a packaging problem wearing a language problem's clothes. Python's stdlib is competing for identifiers in a registry it does not control and cannot reserve names in — which is a familiar shape if you have watched registries bolt namespace verification on after the fact, as the MCP registry's reverse-DNS naming did this year.
Everyone else solved this years ago
Python is the outlier here, and the comparison is not flattering. Rust has always addressed its standard library as std::, with crates.io living in a separate space entirely. Node added the node: prefix for builtins, so require('node:fs') cannot be intercepted by a package called fs. Node has been steadily formalising what its runtime owns for several releases now. Deno went further and made the scheme mandatory in imports, with npm: and jsr: specifiers marking where code comes from at the call site.
In each case the prefix does two jobs: it disambiguates, and it makes provenance visible in the source. The second job is the one Python is quietly giving up by keeping a flat namespace. import json tells a reviewer nothing about whether that is the standard library or a vendored module three directories up. import std.json does.
For anyone reviewing dependency choices — the exercise behind comparing developer tools at all — that visibility is worth more than the shadowing fix. Supply-chain review gets easier when the import line says where the code is from.
What was not decided
This was a discussion, not a decision, and the open questions are substantive rather than procedural.
How much namespace
Stefan Behnel suggested restricting it to from std import random rather than allowing import std.json at the top level — keeping top-level imports unchanged while still giving you an unambiguous way to reach the stdlib. That is a materially different proposal with a materially smaller blast radius.
How much migration
Guido van Rossum confirmed that every standard library module would eventually need migrating. Galindo described the work as "mostly mechanical." Those two statements are compatible and still add up to touching every module in the standard library, which has a way of surfacing non-mechanical cases.
How fast
Thomas Wouters proposed rolling it out incrementally, with new modules shipping under std first. This is the version most likely to happen, and it is also the one that most directly fixes the naming constraint — a brand-new module launched only as std.something never has to check PyPI first.
How many problems at once
Gregory P. Smith's caution is the sharpest thing in the write-up: do not try to solve several problems simultaneously, narrow the proposal to specific objectives. Shadowing, naming freedom, provenance and the long-running question of unbundling the stdlib are four different proposals that currently share one slide. The write-up notes Ruby's gemification as the cautionary precedent on the unbundling end.
Reception was broadly warm — the write-up records that no attendee hated the idea and that many loved it — which is exactly the condition under which a proposal grows scope and dies of it.
What this means if you publish Python packages
Nothing, today. There is no PEP, no implementation and no target version. But the direction matters for two decisions you might be making now.
First, stop treating a short, obvious PyPI name as a long-term asset on the assumption that the stdlib will route around you. If new modules start landing under std, that pressure disappears and so does the implicit protection a squatted name used to confer. Second, if you maintain a backport or a compatibility shim named after a stdlib module, an eventual std namespace changes what "drop-in replacement" means — your users will have two spellings for the same import and will mix them.
The practical move is unglamorous: make your own package's import surface unambiguous now. Single top-level package, named after the distribution, no bare module names that collide with anything in the standard library. If you are picking a name this week, run it through a slug generator for the distribution spelling and check the import name separately — the two are allowed to differ and conflating them is how projects end up with a name that is fine on PyPI and ambiguous in code.
Watch for a PEP. Until there is one, this is a well-received summit talk, and the Python Language Summit has a long history of well-received talks that took five years to become anything. The namespace that already exists in Rust, Node and Deno is the argument; the question is whether Python can adopt it narrowly enough to ship.
FAQ
Would import json stop working?
No. The proposal as presented keeps top-level imports working indefinitely, with std.json and json referring to the same module object. The possibility of a future mode that disables top-level shadowing was mentioned at the summit but not finalised.
Is there a PEP for this?
Not at the time of the summit write-up. This was a discussion session at the 2026 Python Language Summit, opened by Pablo Galindo Salgado, with no PEP number, implementation or target Python version attached.
Why is the module called tomllib and not toml?
Because toml was already taken on PyPI. The same constraint produced graphlib instead of graph, and the summit write-up gives zoneinfo as an example of an unexpected name chosen under the same pressure. That naming constraint is one of the two motivations given for the std namespace.
How do other languages handle this?
Rust addresses its standard library under std:: and keeps crates.io separate. Node supports a node: prefix for builtin modules so a package cannot shadow them. Deno uses mandatory specifiers including npm: and jsr: so the source of an import is visible at the call site. Python's flat namespace is the outlier.
What was the main objection raised?
Gregory P. Smith cautioned against solving multiple problems at once and advised narrowing the proposal to specific objectives. Stefan Behnel proposed a smaller version limited to from std import X. Guido van Rossum noted that every standard library module would eventually need migrating.
Should I rename my package because of this?
No. There is no PEP and no timeline. The useful action is to make sure your package's import name is unambiguous and does not collide with a standard library module, which is good practice regardless of whether a std namespace ever ships.
The shadowing fix is the pitch. Being able to name a new stdlib module after the thing it does is the prize.