Revised PEP 842 revives export keyword for private-by-default modules

A revised PEP 842 proposes an export soft keyword so Python modules can declare which names form their public API, with an export list as the backing store. Author Peter Bierma (ZeroIntensity) reframed the idea after earlier feedback: modules that use export would treat unmarked names as private, aiming to stop accidental leakage of helpers and imports into star-imports, dir(), and external consumers.

The change targets large, long-lived libraries that already maintain ad-hoc public-API lists. Guido van Rossum called the draft a clear improvement and rejected the notion that “everything is public” is a sacred principle, calling it merely the historical default. He wants the PEP aimed at greenfield projects rather than migration paths for every existing codebase, and he urged replacing a proposed warning with a hard ExportError (inheriting from both ImportError and AttributeError).

Paul Moore pressed for a sharper premise: the real question is whether modules should be allowed to opt into private-by-default at all, and how obvious that opt-in must be. An export statement buried hundreds of lines down, he argued, is easy to miss; a module-level marker such as an explicit export = [] near the top would be harder to overlook. A future import was floated and largely rejected, both because future imports imply an eventual language-wide default and because several participants, including Moore, oppose ever making private the global default.

Secondary concerns include test runners that discover cases via dir(), intra-package access to internals without tripping errors, and whether the private-by-default decision should be static so linters can reason about it. Bierma maintains that marking the public surface is less error-prone than scattering private annotations across every helper. The design is still open on the exact opt-in marker and on package-internal escape hatches.