homepage

When a co-routine has delegated computation to another co-routine via "yield from", it is useful to be able to access the delegated-to co-routine.
This proposed enhancement would add a new calculated property to the generator object called "gi_yieldfrom", which returns the delegated-to co-routine (or None).

Attached is my first attempt at implementing this feature.
It includes to implementation, updates to documentation, and added test cases.
I'm not a regular contributor so look forward to any feedback on improving the patch.

I left some comments on Reitveld.
Does this also apply to the new "async def" native coroutines? If not, I think it should be made to.

I think we need some feedback from PyPy & Jython guys on this. I'm not sure that they can expose 'yieldfrom' slot without some performance penalties.

No problem from PyPy.

I've tried to address all the issues raised in the review of the first patch.

Marking this as dependent on issue 24400, as that refactors the PEP 492 implementation to make coroutines their own type (albeit one that shares a memory layout and some attribute names with generators at the C layer).
I'd suggest cr_await as the calculated property for coroutines that corresponds to gi_yieldfrom for generators.

No problem for Cython either.
The change in issue 24400 that makes coroutines real Awaitables also removes surprises for a "cr_await" return value being a coroutine and previously *not* an Awaitable.
The contract for "gi_yieldfrom" is only that the returned value is an Iterator, IIUC?

Please find attached a new patch that exposes 'cr_await' attribute on coroutine objects. I don't think we can merge 'gi_yieldfrom' in 3.5, but 'cr_await' should probably be fine.

Guido indicated on python-dev that he considered it reasonable to view adding gi_yieldfrom as part of the PEP 492 implementation: https://mail.python.org/pipermail/python-dev/2015-June/140498.html
That perspective makes sense to me as well, since it preserves the functional equivalence of native coroutines (cr_await) and generator based coroutines (gi_yieldfrom) from a state introspection perspective.
I've added Larry to the nosy list here to give him the option of veto'ing as release manager, but I think we want both in order to get full debuggability benefits.

For Benno’s original gi_yieldfrom property, I guess the asyncio.coroutines.CoroWrapper class would need updating. The GeneratorWrapper class for @types.coroutine probably should be updated too, since it already supports other internal generator properties.

Larry, what's your opinion on this?
cr_await is a new thing (trivial on the C level) on a new type, it shouldn't break anything. gi_yieldfrom is identical to cr_await. Can we add this to 3.5?

This shouldn't be a problem for Jython.

I'll accept it for 3.5. Can it go in for beta 3, tagged in 48 hours?

New changeset 84eb9a020011 by Yury Selivanov in branch '3.5':
Issue #24450: Add gi_yieldfrom to generators; cr_await to coroutines.
https://hg.python.org/cpython/rev/84eb9a020011
New changeset f4058528ab8c by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24450)
https://hg.python.org/cpython/rev/f4058528ab8c 

Benno, thanks for coming up with the idea and for the patches. Larry, thanks for approving this for 3.5!

New changeset 9bae275e99b3 by Yury Selivanov in branch '3.5':
Issue #24450: Proxy cr_await and gi_yieldfrom in @types.coroutine
https://hg.python.org/cpython/rev/9bae275e99b3
New changeset 4d3bd9b82a62 by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24450)
https://hg.python.org/cpython/rev/4d3bd9b82a62 

New changeset 34460219c0e0 by Yury Selivanov in branch '3.4':
Issue #24450: Proxy gi_yieldfrom & cr_await in asyncio.CoroWrapper
https://hg.python.org/cpython/rev/34460219c0e0
New changeset 3555f7b5eac6 by Yury Selivanov in branch '3.5':
Merge 3.4 (Issue #24450)
https://hg.python.org/cpython/rev/3555f7b5eac6
New changeset 5e9f794fd776 by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24450)
https://hg.python.org/cpython/rev/5e9f794fd776