Editorial pass.

Author: ZeroIntensity

peps/pep-0842.rst

@@ -188,10 +188,8 @@ that provide access to native functionality or otherwise speed up the module
 in some way. These native modules are often prefixed with a leading underscore.
 
 For example, in :term:`CPython`, the :mod:`asyncio` module has a private
-``_asyncio`` accelerator module, so a trained eye, reading ``_asyncio``
-in Python code may read as accessing the C accelerator. This requires the
-reviewer to find where the import is defined as determine which version
-of ``asyncio`` is being used.
+``_asyncio`` accelerator module, so a reader seeing ``_asyncio`` may take it
+to mean the C accelerator and not the normal module.
 
 
 Imports are suggested by language servers and linters
@@ -226,7 +224,7 @@ In Python 3.7, an import to the :mod:`errno` module was removed from :mod:`os`.
 This caused a lot of breakage:
 
 * `python/cpython#77847 <https://github.com/python/cpython/issues/77847>`__
-* `Qiskit/quiskit#1253 <https://github.com/Qiskit/qiskit/issues/1253>`__
+* `Qiskit/qiskit#1253 <https://github.com/Qiskit/qiskit/issues/1253>`__
 * `uxlfoundation/oneMath#68 <https://github.com/uxlfoundation/oneMath/issues/68>`__
 * `intel/bmap-tools#34 <https://github.com/intel/bmap-tools/issues/34>`__
 * `Red Hat Bug 1583196 <https://bugzilla.redhat.com/show_bug.cgi?id=1583196>`__
@@ -275,7 +273,7 @@ Linters cannot fight against imports
 
 As a solution to the above problem, one might suggest that linters should
 simply warn against importing modules from another module. The primary issue
-with this is that this pattern is particular common in ``__init__.py`` files
+with this is that this pattern is particularly common in ``__init__.py`` files
 to move all packages into one namespace. For example:
 
 .. code-block::
@@ -721,6 +719,10 @@ The grammar is changed to allow for the standalone ``export`` statement and
       | &"export" export_stmt
 
 
+Note that augmented assignments (``x += y``) are disallowed through a PEG action
+at compile time.
+
+
 Standalone exports
 ******************
 
@@ -748,13 +750,6 @@ is semantically equivalent to:
    if "NAME1" not in globals():
       raise NameError(...)
 
-   try:
-      __export__
-   except NameError:
-      __export__ = []
-
-   __export__.append("NAME1")
-
    if "NAME2" not in globals():
       raise NameError(...)
 
@@ -763,6 +758,7 @@ is semantically equivalent to:
    except NameError:
       __export__ = []
 
+   __export__.append("NAME1")
    __export__.append("NAME2")
 
 
@@ -781,7 +777,7 @@ As an example, the following code:
 
 .. code-block:: python+soft-keywords:export
 
-   export NAME, NAME2 = VALUE1, VALUE2
+   export NAME1, NAME2 = VALUE1, VALUE2
 
 is semantically equivalent to:
 
@@ -961,6 +957,16 @@ It does *not* break backwards compatibility, meaning that existing code using
 "``export``" as a variable name will continue to work.
 
 
+Relation to ``-W error``
+------------------------
+
+While this PEP does not break any existing applications, it may break
+tests for downstream users of packages who choose to adopt this PEP, as
+many popular testing frameworks, such as `pytest
+<https://docs.pytest.org/en/stable/>`__, run with warnings-as-errors enabled
+by default.
+
+
 Security Implications
 =====================
 
@@ -1133,7 +1139,8 @@ syntax. For example:
 
 This is the author's next preferred solution after ``export`` syntax, but it
 does come with some caveats. In particular, there's no easy way to export
-simple variables without duplicating
+simple variables without duplicating the name, which many dislike due to the
+violation of the DRY principle.
 
 
 Open Issues
@@ -1157,7 +1164,7 @@ Paul Moore, Steve Dower, and Barry Warsaw.
 Change History
 ==============
 
-* 06-Aug-2026
+* 05-Aug-2026
 
   - Added an ``export`` statement.
   - Added the ``ExportWarning`` builtin type, which is now emitted instead of a