Some revisions.

Author: ZeroIntensity

peps/pep-0828.rst

@@ -153,8 +153,10 @@ If no argument is supplied, ``value`` will be ``None``.
 ``return`` statements inside asynchronous generators
 ----------------------------------------------------
 
-In an asynchronous generator, the statement ``return expression`` is
-roughly equivalent to ``raise StopAsyncIteration(expression)``. However,
+In the body of an asynchronous generator function, the statement
+``return expression`` is roughly equivalent to
+``raise StopAsyncIteration(expression)``. However, similar to implicit
+``StopIteration`` exceptions raised inside of synchronous generators,
 the exception cannot be caught in the body of the asynchronous generator.
 
 
@@ -241,6 +243,12 @@ Backwards Compatibility
 
 This PEP introduces a backwards-compatible syntax change.
 
+The addition of the ``value`` attribute to :exc:`StopAsyncIteration` is a
+minor semantic change to an existing builtin exception, but is unlikely
+to affect existing code in practice, as it mirrors the existing ``value``
+attribute on :exc:`StopIteration` and does not affect any other behavior
+on ``StopAsyncIteration`` or the asynchronous iterator protocol.
+
 
 Security Implications
 =====================
@@ -257,7 +265,7 @@ intends to be very intuitive; users should be able to naturally reach
 for ``async yield from`` given their own background knowledge about generators
 in Python. This can be encouraged further by suggesting
 ``async yield from`` in the error message when a user attempts to use
-``yield from`` in a synchronous generator.
+``yield from`` in an asynchronous generator.
 
 
 Reference Implementation
@@ -319,10 +327,11 @@ to the caller:
 
 Now, imagine that the developer wants to add an ``await`` call somewhere in
 this function; the ``yield from something_else()`` statement would suddenly
-become invalid. With the current proposal, the existence of ``async yield from``
-(which would ideally be included in the error message) would make it much
-clearer that ``something_else`` must also be asynchronous in order to use it
-in the function.
+become a runtime :class:`TypeError` (as opposed to a compile-time
+:class:`SyntaxError`). With the current proposal, the existence of
+``async yield from`` (which would ideally be included in the error message)
+would make it much clearer that ``something_else`` must also be asynchronous
+in order to delegate to it.
 
 Finally, this would preclude the introduction of support for synchronous
 subgenerator delegation inside asynchronous generators (see
@@ -337,7 +346,7 @@ are solvable given time.
 -----------------------------------------------------
 
 As an alternate solution to the verbosity of ``async yield from``, some have
-suggested using spellings such as ``async from`` in order to cut down the
+suggested using spellings such as ``async from`` in order to cut down on the
 verbosity. Unfortunately, changes in the spelling will likely hurt the
 readability of the syntax as a whole.
 
@@ -375,11 +384,11 @@ generators:
 
 .. code-block:: python
 
-   async def agen():
-    async with asyncio.timeout(3):
-        # If the timeout fails, then an asyncio.TimeoutError would be raised
-        # in a *synchronous* generator!
-        yield from subgen()
+    async def agen():
+        async with asyncio.timeout(3):
+            # If the timeout fails, then an asyncio.TimeoutError would be raised
+            # in a *synchronous* generator!
+            yield from subgen()
 
 
 To quote Brandt Bucher (paraphrased):
@@ -408,7 +417,7 @@ collecting outside opinions about the design and implementation.
 Change History
 ==============
 
-- 22-May-2026
+- 26-May-2026
 
     - Removed support for delegating to a synchronous subgenerator (via
       a plain ``yield from``).