More editorial fixes.

Author: ZeroIntensity

peps/pep-0842.rst

@@ -46,7 +46,7 @@ For example:
 
 
 This is **not** intended to be an access modifier for Python; see
-:ref:`pep-842-not-an-access-modifier`.
+:ref:`the rationale <pep-842-not-an-access-modifier>`.
 
 
 Motivation
@@ -162,7 +162,7 @@ users found useful functionality in a module's private API, and nothing was
 discouraging them from using it.
 
 In the standard library, a prime example of this is the :mod:`ctypes` module.
-``ctypes`` is full of public APIs that are subject to Python's backwards
+``ctypes`` is full of stable APIs that are subject to Python's backwards
 compatibility policy, but contain a leading underscore. For example:
 
 1. :class:`ctypes._CFuncPtr`
@@ -322,7 +322,7 @@ downstream breakage. In this case, the library maintainer has to make a decision
    to take place.
 2. Commit to maintaining the private API as public, increasing the burden on
    themselves and encountering some of the problems described in
-   :ref:`pep-842-prefixed-public`.
+   :ref:`the motivation <pep-842-prefixed-public>`.
 
 This PEP is not intended to solve this problem entirely, but instead is meant
 to mitigate it by making it much clearer that a user is accessing a private name;
@@ -385,7 +385,7 @@ module. ``ExportWarning`` inherits from :class:`Warning` and defines no other
 attributes.
 
 Though allowed, it is not intended to be emitted by user code; instead, it is
-meant for emission by a :class:`module object <types.ModuleType>` when accessing
+meant for emission by a :class:`module <types.ModuleType>` object when accessing
 a name that is not in ``__export__``; see :ref:`pep-842-attribute-access`.
 
 
@@ -903,6 +903,15 @@ is semantically equivalent to:
 Similar to the other ``export`` constructs, this must occur at the module-level;
 using it elsewhere is a :class:`SyntaxError`.
 
+Lazy imports, as described by :pep:`810`, are also allowed to be used with ``from``
+exports. For example:
+
+.. code-block:: python+soft-keywords:export
+
+   lazy from foo export bar
+
+The existing rules for lazy imports apply here as well.
+
 
 Rationale
 =========
@@ -1038,7 +1047,7 @@ annotating their own code.
 
 In addition, it's not clear that there's any good spelling for this
 behavior that covers all cases. The "obvious" solution is to add a
-new :ref:`future statement <future>` that makes ``__all__`` more strict, but
+new :ref:`future statement <python:future>` that makes ``__all__`` more strict, but
 that isn't backwards compatible; codebases wanting to opt-in to the behavior
 described by this PEP must use a spelling that works on all supported Python
 versions in order to keep their code working on older versions, so any