PEP 789: maybe just deprecate asyncgens?

peps/pep-0789.rst

@@ -83,7 +83,7 @@ straightforward ``async for`` loop:
         try:
             while True:
                 with timeout(max_time):
-                    yield anext(ait)
+                    yield await anext(ait)
         except StopAsyncIteration:
             return
 
@@ -105,7 +105,7 @@ then yield *outside* that context.
         try:
             while True:
                 with timeout(max_time):
-                    tmp = anext(ait)
+                    tmp = await anext(ait)
                 yield tmp
         except StopAsyncIteration:
             return
@@ -449,9 +449,6 @@ cancel scope semantics, we will ensure that the documentation of
 implementation sections of this PEP.  We anticipate consulting most such
 maintainers for their feedback on the draft PEP.
 
-.. [#exp-report] see `Zac's experience report here
-    <https://discuss.python.org/t/using-exceptiongroup-at-anthropic-experience-report/20888>`__
-
 
 Rejected alternatives
 =====================
@@ -471,6 +468,32 @@ relate to this proposal, and to PEP 533 and PEP 568, then see `this comment
 <https://discuss.python.org/t/preventing-yield-inside-certain-context-managers/1091>`__.
 
 
+Deprecate async generators entirely
+-----------------------------------
+
+At the 2024 language summit, several attendees suggested instead deprecating async
+generators *in toto.*  I'm not opposed to that [#exp-report]_ -- it's a reasonable
+alternative to this PEP, albeit with enormous backwards-compatibilty costs.
+Two library features that I think would be important in this scenario are:
+
+1. Ergonomic async iterables in the standard library.  This could be addressed by
+   adding ``__aiter__`` to ``asyncio.Queue``, and a ``close()`` method to allow
+   for finite iteration.  This would almost exactly match Trio's SendChannel /
+   ReceiveChannel interface, which has been working well in production for years.
+
+2. An alternative convenient syntax to define async context managers with an
+   ``@asynccontextmanager`` decorator.  I think we could make this work by
+   injecting a magic awaitable as a positional-only first argument, but haven't
+   prototyped that yet.
+
+Both of these could be prototyped in asyncio-compatible downstream libraries
+such as ``anyio``, and later considered for inclusion in the standard library.
+
+
+.. [#exp-report] see `Zac's experience report here
+    <https://discuss.python.org/t/using-exceptiongroup-at-anthropic-experience-report/20888>`__
+
+
 Copyright
 =========