Skip to content

Commit b5ca56c

Browse files
Clarify behavior of yield from in async generators
1 parent 35758a2 commit b5ca56c

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

peps/pep-0828.rst

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -374,8 +374,9 @@ Using ``yield from`` to delegate to asynchronous generators
374374

375375
It has been argued that many developers may intuitively believe that using a
376376
plain ``yield from`` inside an asynchronous generator would also delegate to
377-
an asynchronous subgenerator rather than a synchronous subgenerator, so it was
378-
proposed to make ``yield from`` always delegate to an asynchronous subgenerator.
377+
an asynchronous subgenerator rather than a synchronous subgenerator. As such,
378+
it was proposed to make ``yield from`` always delegate to an asynchronous
379+
subgenerator.
379380

380381
For example:
381382

@@ -397,7 +398,7 @@ synchronous constructs always have an asynchronous counterpart for use in
397398
asynchronous functions, instead of implicitly switching protocols depending on
398399
the type of function it is used in. For example, :keyword:`with` always means that the
399400
:term:`synchronous context management protocol <context management protocol>` will
400-
be invoked.
401+
be invoked, even when used in an ``async def`` function.
401402

402403
Finally, this would leave a gap in asynchronous generators, because there would be
403404
no mechanism for delegating to a synchronous subgenerator. Even if this is not a

0 commit comments

Comments
 (0)