Fix build errors.

Author: ZeroIntensity

peps/pep-0842.rst

@@ -14,7 +14,7 @@ Abstract
 ========
 
 This PEP proposes an ``__export__`` variable that modules can define to
-express intent behind visibility to variables from outside the module.
+express intent about the visibility of variables from outside the module.
 
 For example:
 
@@ -52,8 +52,8 @@ Motivation
 ==========
 
 
-Module names need privacy
--------------------------
+Module-level names need privacy
+-------------------------------
 
 A developer is writing a Python module. The module is intended to have one
 "public" class -- a class that is intended for users of the module -- called
@@ -105,7 +105,7 @@ convention; even if this PEP is accepted, it's expected that "underscored"
 names (names prefixed with a leading ``_``) will remain a staple of Python
 for years to come. The purpose of this PEP is not to eliminate the need for
 ``_`` in module-level names, but instead to clear up corner cases where a
-private name is ambigious or tempting. In other words, this PEP is intended
+private name is ambiguous or tempting. In other words, this PEP is intended
 to improve expressiveness and clarity with private APIs, *not* to add brand
 new functionality.
 
@@ -145,6 +145,8 @@ The solution to this is to also prefix every imported name with ``_``:
    import tabnanny as _tabnanny
 
 
+But, again, this sprinkles the code with even more underscored names.
+
 
 .. _pep-842-prefixed-public:
 
@@ -167,15 +169,15 @@ compatibility policy, but contain a leading underscore. For example:
 This sends the wrong message to consumers of the API. When seeing things like
 this in a codebase, it makes it seem like the code is opting out of backwards
 compatibility, or that an underscored name does not mean "private" in the
-module. In both cases, consumers are inclined to reach for more private names,
-making this problem worse.
+module. In both cases, consumers are inclined to reach for more private names
+(because there's no apparent consequence for doing so), making this problem worse.
 
 
 We want to be nice to users, not shrug them away
 ------------------------------------------------
 
 When a user decides to use a private API, accidentally or not, they will
-inevitably be broken by the library author(s). In many cases, this results
+inevitably be broken by the library author. In many cases, this results
 in a bug report asking for the API to be fixed or restored to prevent
 downstream breakage. In this case, the library maintainer has to make a decision:
 
@@ -204,31 +206,32 @@ is named and placed well, then a user often won't need to reach for the
 documentation. Python is no exception to this.
 
 When prototyping, it's typical for someone to use :func:`dir` or :func:`help`
-in Python's interactive :term:`REPL` to look for attributes or methods that
-are useful to them. In this case, if something is intuitive enough for the
-user, they will simply reach for it without checking the documentation first.
-In a language as dynamic as Python, the way people consume APIs is also dynamic.
+in Python's interactive :term:`REPL` to look for attributes that are useful to
+them. In this case, if something is intuitive enough for the user, they will
+simply reach for it without checking the documentation first. In a language
+as dynamic as Python, the way people consume APIs is also dynamic.
 
 
 ``__all__`` is only a convention
 --------------------------------
 
 The fundamental issue here is that Python has no way to express which names
-in a module are "private" or "public" -- or, in other words, which names are
-designed to be stable APIs for users. Prefixing is an option, but given the
+in a module are "private" or "public". Prefixing is an option, but given the
 reasons above, it's not always a bulletproof (or nice) solution for library
 authors.
 
-Currently, the convention for expressing which names are public is done through
-a module's :attr:`__all__` variable. This has two major downsides:
+Currently, the other convention for expressing which names are public is
+done through a module's ``__all__`` variable. This has two major downsides:
 
 1. ``__all__`` often gets out of sync, because as developers add, change, or
    remove names from their module, there is often nothing pushing them towards
    changing ``__all__``, because again, using it to list public names is only
-   a *convention* and not enforced by anything.
+   a convention and not enforced by anything.
 2. ``__all__`` is not always exhaustive. See the :ref:`rejected ideas
    <pep-842-all-for-exports>` for examples on where the items in ``__all__``
-   might only be a subset of the "public" names in a module.
+   might only be a subset of the "public" names in a module. In short, it can
+   be difficult to control namespace pollution and declare all public names in
+   ``__all__`` simultaneously.
 
 This PEP intends to solve both of these problems with a new ``__export__`` variable.
 
@@ -294,7 +297,7 @@ Module attribute access
 When ``__export__`` is present in a module's globals, all access to attributes
 present on the module object will also check if the attribute name is present
 in ``__export__`` (via ``__contains__`` or through iteration, as specified previously).
-If the attribute name is not present in ``__export__``, then an :exc:`RuntimeWarning`
+If the attribute name is not present in ``__export__``, then a :exc:`RuntimeWarning`
 is emitted. For example:
 
 .. code-block:: python
@@ -311,7 +314,7 @@ is emitted. For example:
    >>> spam.a
    42
    >>> spam.b
-   <python-input-4>:1: RuntimeWarning: 'b' is not exported by 'spam'
+   <python-input-2>:1: RuntimeWarning: 'b' is not exported by 'spam'
    24
 
 
@@ -492,11 +495,13 @@ following code:
 
 .. code-block:: python
 
-   __all__ = __export__
+   if "__all__" not in globals():
+      __all__ = __export__
 
    def _is_dunder_name(name):
        return (len(name) > 4) and name.startswith("__") and name.endswith("__")
 
+   # Attributes not in the __dict__ fall back to the normal lookup
    def __getattribute__(name):
        try:
            value = globals()[name]
@@ -584,7 +589,7 @@ A reference implementation of this PEP can be found
 `here <https://github.com/python/cpython/compare/main...ZeroIntensity:cpython:experiments/module-exports>`__.
 
 Performance
-***********
+-----------
 
 The reference implementation does not currently implement any optimizations
 to reduce the overhead of the ``__export__`` lookup or iteration, meaning
@@ -682,10 +687,11 @@ behind this PEP.
 Change History
 ==============
 
-- 01-Aug-2026:
-  * Accessing an unexported attribute now emits a :exc:`RuntimeWarning` instead
+* 01-Aug-2026
+
+  - Accessing an unexported attribute now emits a :exc:`RuntimeWarning` instead
     of raising an :exc:`ImportError`.
-  * Significantly overhauled the motivation section.
+  - Significantly overhauled the motivation section.
 
 
 Copyright