Apply ZeroIntensity's PEP 843 review requests

Peter Bierma (ZeroIntensity) offered to sponsor PEP 843 and asked to
be listed as its CODEOWNERS reviewer, so add both. He also flagged
that several section headers had underlines longer than their titles;
fix all of those to satisfy strict RST underline-length checking.

Author: NeilGirdhar

.github/CODEOWNERS

@@ -715,6 +715,7 @@ peps/pep-0837.rst  @serhiy-storchaka
 peps/pep-0838.rst  @AlexWaygood
 peps/pep-0840.rst  @jeremyhylton @gvanrossum
 peps/pep-0842.rst  @ZeroIntensity
+peps/pep-0843.rst  @ZeroIntensity
 # ...
 peps/pep-2026.rst  @hugovk
 # ...

peps/pep-0843.rst

@@ -1,6 +1,7 @@
 PEP: 843
 Title: Export Statement for DRY Re-exports
 Author: Neil Girdhar <mistersheik@gmail.com>
+Sponsor: Peter Bierma <peter@python.org>
 Discussions-To: Pending
 Status: Draft
 Type: Standards Track
@@ -42,7 +43,7 @@ statement. Nothing is left to sync by hand, and no alias needs decoding.
 
 
 Relationship to PEP 842
-========================
+=======================
 
 Both PEPs start from the same discomfort with ``__all__``, and agree on
 the same core mechanism for re-exports: a statement of the shape ``from
@@ -105,7 +106,7 @@ see a bare ``import x`` as unused and remove it.
 
 
 ``__all__`` conflates two concerns
--------------------------------------
+----------------------------------
 
 Hand-maintained ``__all__`` also mixes two distinct concerns in one
 file: the list of imports (an implementation detail of how the
@@ -119,7 +120,7 @@ autofixers routinely delete it rather than surface the omission.
 
 
 Underscores solve a different problem
---------------------------------------
+-------------------------------------
 
 A natural response is: "just prefix internal names with an underscore."
 But the privacy this PEP cares about lives at the package level, not the
@@ -205,7 +206,7 @@ export is the use.
 
 
 Wildcard form
------------------
+-------------
 
 This proposal also includes a wildcard form, ``from <module> export *``.
 It binds every name that ``from <module> import *`` would bind, using the
@@ -241,7 +242,7 @@ machinery already computes to execute a wildcard import.
 
 
 Lazy exports
------------------
+------------
 
 :pep:`810` adds a ``lazy`` soft keyword that defers a ``from ... import``
 statement until the imported name is first used: ``lazy from <module>
@@ -341,7 +342,7 @@ exactly the shape a hub module (`How to Teach This`_) already takes.
 
 
 Interaction with ``__all__``
------------------------------
+----------------------------
 
 A module may freely mix ``from ... export ...`` statements with a
 manually maintained ``__all__``, or with ``__all__ +=`` /
@@ -369,7 +370,7 @@ attribute-access hiding is a `non-goal <Non-goals_>`_ of this PEP.
 
 
 Semantic implementation
-------------------------
+-----------------------
 
 Each ``from <module> export <name> as <alias>`` statement is equivalent
 to:
@@ -402,7 +403,7 @@ Rationale
 =========
 
 Why a keyword and not a decorator
------------------------------------
+---------------------------------
 
 A ``@public``-style decorator, as in the third-party ``atpublic``
 package, works neatly for individually defined functions and classes,
@@ -421,7 +422,7 @@ both problems, because it's part of the import statement itself; it
 adds nothing beyond the import that would exist anyway.
 
 Why only re-exports
------------------------------
+-------------------
 
 This PEP deliberately omits a way to mark a fresh ``def``, ``class``, or
 assignment as exported where it's defined. Some smaller libraries and
@@ -453,7 +454,7 @@ propose a definition-site marker if real-world evidence for that gap
 emerges; this PEP doesn't need to solve it to solve the re-export problem.
 
 Why no runtime enforcement
------------------------------
+--------------------------
 
 The author finds runtime access restriction appealing on its own merits,
 and excludes it here purely on scope grounds. :pep:`842` proposes exactly
@@ -479,7 +480,7 @@ with the syntax that produces that ``__all__`` in the first place.
 
 
 Backwards Compatibility
-========================
+=======================
 
 ``export`` is a soft keyword, following the same approach as ``match``,
 ``case``, and ``type``. Python treats it specially only in the one
@@ -504,13 +505,13 @@ minimum supported version catches up:
 
 
 Security Implications
-=======================
+=====================
 
 This PEP has no known security implications.
 
 
 How to Teach This
-====================
+=================
 
 Documentation should teach ``from <module> export <name>`` as part of a
 named layout, the **hub-and-internals** pattern, not as an isolated
@@ -564,18 +565,18 @@ plugins.
 
 
 Reference Implementation
-===========================
+========================
 
 No reference implementation exists yet. A prototype could be built as a
 source-to-source transform (similar to early prototypes of ``match``
 statements) before committing to grammar changes in CPython.
 
 
 Rejected Ideas
-================
+==============
 
 Alternative surface syntax
--------------------------------
+--------------------------
 
 This PEP considered two other spellings for the re-export statement:
 
@@ -594,10 +595,10 @@ This PEP considered two other spellings for the re-export statement:
 
 
 Open Issues
-=============
+===========
 
 Should ``export *`` require the source module to define ``__all__``?
----------------------------------------------------------------------
+--------------------------------------------------------------------
 
 The two-tier layout that motivates the wildcard form (see
 `Specification`_) depends on the internal module having deliberately
@@ -619,7 +620,7 @@ error if it doesn't?
 
 
 Acknowledgements
-===================
+================
 
 This PEP grew out of discussion on :pep:`842`, particularly
 contributions from Peter Bierma, Alex Grönholm, Guido van Rossum, Barry
@@ -640,7 +641,7 @@ Change History
 
 
 Copyright
-===========
+=========
 
 This document is placed in the public domain or under the
 CC0-1.0-Universal license, whichever is more permissive.