PEP 843: Export Statement for DRY Re-exports by NeilGirdhar · Pull Request #5078 · python/peps

NeilGirdhar · 2026-08-05T19:11:44Z

Basic requirements (all PEP Types)

Standards Track requirements

read-the-docs-community · 2026-08-05T19:21:37Z

Documentation build overview

📚 pep-previews | 🛠️ Build #33936046 | 📁 Comparing 14dda0d against latest (0475dc3)

🔍 Preview build

4 files changed

+ pep-0843/index.html
± index.html
± numerical/index.html
± pep-0000/index.html

warsaw · 2026-08-05T22:47:15Z

+* Restrict runtime attribute access to non-exported names, or change
+  ``__getattr__`` semantics. See `Why no runtime enforcement`_.
+* Mark a freshly written ``def``, ``class``, or assignment as exported at
+  its definition site, the way :pep:`829`'s ``atpublic`` package does with


PEP 829 and atpublic are really orthogonal. The latter is a package that has decades long use in the real world. The connection is that with the next version (likely atpublic 8.0.0 with an alpha already released), you'll be able to pip install atpublic[install] to get the public() and private() decorators automatically installed into builtins at interpreter startup time.

Thanks for the correction, I'll remove mention of PEP 829!

ZeroIntensity · 2026-08-05T23:31:11Z

+PEP: 843
+Title: Export Statement for DRY Re-exports
+Author: Neil Girdhar <mistersheik@gmail.com>
+Discussions-To: https://discuss.python.org/t/108353


Using the 842 thread is fine for the post-history, but you're going to want your own thread for this PEP. Mark this as "Pending" for now; you'll create the thread after merging.

That makes perfect sense, thank you!

Yes, discussion should be in another topic than 842, as that one is long enough already!

As there's no sponsor for this one yet, it should be in the Ideas category.

@ZeroIntensity Relatedly, as you're working on a new revision, you may want to lock the old thread (by flagging and asking mods) until you post the new topic. This is something Brett has done to manage his long PEP discussions.

ZeroIntensity · 2026-08-05T23:31:48Z

+``__all__`` and triggers an ``ExportWarning`` on access to anything left
+out.


You should probably clarify that ExportWarning is specific to 842.

I agree: the paragraph structure was confusing. I completely separated the commonalities from the PEP 842-specific points for clarity.

ZeroIntensity · 2026-08-05T23:32:35Z

+wildcard equivalent to `Wildcard form`_ and no lazy equivalent to `Lazy
+exports`_. This PEP takes only that one slice, deliberately leaving out


PEP 842 allows lazy imports, as it is in the grammar (though I haven't tested the implementation for it). I clarified that in my draft.

Thanks for clarifying; I've corrected my exposition.

ZeroIntensity · 2026-08-05T23:34:49Z

 peps/pep-0838.rst  @AlexWaygood
 peps/pep-0840.rst  @jeremyhylton @gvanrossum
 peps/pep-0842.rst  @ZeroIntensity
+peps/pep-0843.rst  @NeilGirdhar


Our (GitHub's?) rule is that you need to be a member of the python organization on GitHub to be listed as a code owner. The core dev sponsor is listed here instead.

Oh, of course! Removed, thanks!

ZeroIntensity · 2026-08-05T23:36:46Z

@@ -0,0 +1,623 @@
+PEP: 843


For the record, you typically need a core dev sponsor before assigning a number. I'm open to sponsoring, but I want to see what happens with the new 842 revision first.

Awesome!! No rush on my end. Happy to wait and see how the new PEP 842 revision goes before asking anyone to commit. Thanks for taking the time to look over my PEP so carefully.

Yes, we can keep this open as a courtesy for a bit, but PEPs from non-core devs do need a sponsor.

We normally only assign numbers when there's a sponsor. There's quite a bit of uncertainty whether this will get one, and some time until we'll know the answer.

Do we want to assign 843 already to this? Or use the usual 9999 placeholder for now?

JelleZijlstra · 2026-08-06T00:31:55Z

@@ -0,0 +1,623 @@
+PEP: 843


Yes, we can keep this open as a courtesy for a bit, but PEPs from non-core devs do need a sponsor.

JelleZijlstra · 2026-08-06T00:32:56Z

+in sync by hand every time the public layout changes.
+
+The second is the reflexive-alias idiom, ``from x import y as y``. Type
+checkers (like mypy even in strict mode) treat it as a signal that the


Why "even"? It's a documented part of the type system.

I was trying to emphasize the universality of the rule, but it didn't come across.

JelleZijlstra · 2026-08-06T00:33:55Z

+==========
+
+This section is grounded in existing, widely-used libraries rather than
+a hypothetical ``spam`` module.


Strange wording

Yeah, this was a weak start. Grounded in affirmative statements instead.

JelleZijlstra · 2026-08-06T00:34:46Z

+file: the list of imports (an implementation detail of how the
+flattening is wired up) and the declaration of the public API (a promise
+to users). The two live in separate statements at different places in
+the file, and a reviewer must check them against each other by eye.


Or rely on a linter that warns when they're out of sync.

Good point. I softened the wording. But often linters do the wrong thing and wipe out the import rather than adding to __all__, so linters aren't a perfect fix.

JelleZijlstra · 2026-08-06T00:36:53Z

+``atpublic`` works around this with a function-call form,
+``public(some_imported_name)``, but that reintroduces the double-write
+this PEP removes: the name is written once in the import and again as an
+argument to ``public()``. A statement-level ``export`` keyword avoids


It also doesn't work well with aliases

Thank you!!

hugovk · 2026-08-06T03:36:15Z

Please add anthe new PEP checklist to the top post, and start checking things off:

https://github.com/python/peps/blob/main/.github/PULL_REQUEST_TEMPLATE/Add%20a%20new%20PEP.md

NeilGirdhar requested a review from a team as a code owner August 5, 2026 19:11

NeilGirdhar force-pushed the main branch from 7f43a14 to 7d0cc81 Compare August 5, 2026 19:18

NeilGirdhar force-pushed the main branch from 7d0cc81 to aa8425d Compare August 5, 2026 22:03

warsaw reviewed Aug 5, 2026

View reviewed changes

NeilGirdhar force-pushed the main branch from aa8425d to ee80ce9 Compare August 5, 2026 22:52

ZeroIntensity reviewed Aug 5, 2026

View reviewed changes

NeilGirdhar force-pushed the main branch from ee80ce9 to 8bfc6d2 Compare August 6, 2026 00:06

JelleZijlstra reviewed Aug 6, 2026

View reviewed changes

NeilGirdhar force-pushed the main branch from 8bfc6d2 to 0995a62 Compare August 6, 2026 01:19

Add PEP 843

14dda0d

NeilGirdhar force-pushed the main branch from 0995a62 to 14dda0d Compare August 6, 2026 01:22

hugovk changed the title ~~Add PEP 843: Export Statement for DRY Re-exports~~ PEP 843: Export Statement for DRY Re-exports Aug 6, 2026

		``__all__`` and triggers an ``ExportWarning`` on access to anything left
		out.

		wildcard equivalent to `Wildcard form`_ and no lazy equivalent to `Lazy
		exports`_. This PEP takes only that one slice, deliberately leaving out

Uh oh!

Uh oh!

Conversation

NeilGirdhar commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Basic requirements (all PEP Types)

Standards Track requirements

Uh oh!

read-the-docs-community Bot commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Documentation build overview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NeilGirdhar Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hugovk commented Aug 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

NeilGirdhar commented Aug 5, 2026 •

edited

Loading

read-the-docs-community Bot commented Aug 5, 2026 •

edited

Loading

NeilGirdhar Aug 5, 2026 •

edited

Loading