-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cr_await calculated property to coroutine object #68638
Comments
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 bpo-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 bpo-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': New changeset f4058528ab8c by Yury Selivanov in branch 'default': |
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': New changeset 4d3bd9b82a62 by Yury Selivanov in branch 'default': |
New changeset 34460219c0e0 by Yury Selivanov in branch '3.4': New changeset 3555f7b5eac6 by Yury Selivanov in branch '3.5': New changeset 5e9f794fd776 by Yury Selivanov in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: