PEP 806: fixes from initial review

Author: Zac-HD

peps/pep-9999.rst peps/pep-806.rstpeps/pep-9999.rst renamed to peps/pep-806.rst

@@ -1,4 +1,4 @@
-PEP: 9999
+PEP: 806
 Title: Mixed sync/async context managers with precise async marking
 Author: Zac Hatfield-Dodds <zac@zhd.dev>
 Sponsor: Jelle Zijlstra <jelle.zijlstra@gmail.com>
@@ -123,7 +123,7 @@ managers in the same way as current multi-context ``with`` statements,
 except that those prefixed by the ``async`` keyword use the ``__aenter__`` /
 ``__aexit__`` protocol.
 
-Only the ``with`` statement is modified; ``async with async cm():`` is a 
+Only the ``with`` statement is modified; ``async with async ctx():`` is a
 syntax error.
 
 
@@ -158,7 +158,7 @@ Workaround: an ``as_acm()`` wrapper
 -----------------------------------
 
 It is easy to implement a helper function which wraps a synchronous context
-manager in an async cm.  For example:
+manager in an async context manager.  For example:
 
 .. code-block:: python
 
@@ -195,8 +195,8 @@ which allows for explicit entry of sync and/or async context managers.
         f = stack.enter_context(open('file'))
         ...
 
-However, :class:`~contextlib.AsyncExitStack` introduces significant complexity 
-and potential for errors - it's easy to violate properties that syntactic use 
+However, :class:`~contextlib.AsyncExitStack` introduces significant complexity
+and potential for errors - it's easy to violate properties that syntactic use
 of context managers would guarantee, such as 'last-in, first-out' order.
 
 
@@ -220,27 +220,32 @@ It also requires either distinguishing sync from async context managers using
 something like a tagged union - perhaps overload an operator so that, e.g.,
 ``async_ @ acquire_lock()`` works - or else guessing what to do with objects
 that implement both sync and async context-manager protocols.
+Finally, it has the error-prone semantics around exception handling which led
+`contextlib.nested()`__ to be deprecated in favor of the multi-argument
+``with`` statement.
+
+__ https://docs.python.org/2.7/library/contextlib.html#contextlib.nested
 
 
 Syntax: allow ``async with sync_cm, async_cm:``
 -----------------------------------------------
 
 An early draft of this proposal used ``async with`` for the entire statement
-when mixing context managers, *if* there is at least one async cm:
+when mixing context managers, *if* there is at least one async context manager:
 
 .. code-block:: python
 
     # Rejected approach
     async with (
         acquire_lock(),
-        open('config.json') as f,  # actually a sync cm, surprise!
+        open('config.json') as f,  # actually sync, surprise!
     ):
         ...
 
-Requiring an async cm maintains the syntax/scheduler link, but at the cost
-of setting invisible constraints on future code changes.  Removing one of
-several context managers could cause runtime errors, if that happened to be
-the last async cm!
+Requiring an async context manager maintains the syntax/scheduler link, but at
+the cost of setting invisible constraints on future code changes.  Removing
+one of several context managers could cause runtime errors, if that happened
+to be the last async context manager!
 
 Explicit is better than implicit.
 
@@ -267,7 +272,7 @@ Thanks to Rob Rolls for `proposing`__ ``with async``.  Thanks also to the many
 other people with whom we discussed this problem and possible solutions at the
 PyCon 2025 sprints, on Discuss, and at work.
 
-__: https://discuss.python.org/t/allow-mixed-sync-async-context-managers-in-async-with-statements/92939/10
+__ https://discuss.python.org/t/allow-mixed-sync-async-context-managers-in-async-with-statements/92939/10
 
 
 Copyright