Add cr_await calculated property to coroutine object

[bennoleslie]

BPO	24450
Nosy	@ncoghlan, @scoder, @larryhastings, @ethanfurman, @vadmium, @1st1
Dependencies	bpo-24400: Awaitable ABC incompatible with functools.singledispatch
Files	gi_yieldfrom.v0.patch: Initial potential implementation of the gi_yieldfrom property gi_yieldfrom.v1.patch: Update patch with better testing coverage and documentation cr_await.patch

^{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:

assignee = 'https://github.com/1st1'
closed_at = <Date 2015-07-03.04:25:26.587>
created_at = <Date 2015-06-14.10:29:47.577>
labels = ['interpreter-core', 'type-feature']
title = 'Add cr_await calculated property to coroutine object'
updated_at = <Date 2015-07-03.04:42:15.615>
user = 'https://bugs.python.org/bennoleslie'

bugs.python.org fields:

activity = <Date 2015-07-03.04:42:15.615>
actor = 'python-dev'
assignee = 'yselivanov'
closed = True
closed_date = <Date 2015-07-03.04:25:26.587>
closer = 'yselivanov'
components = ['Interpreter Core']
creation = <Date 2015-06-14.10:29:47.577>
creator = 'bennoleslie'
dependencies = ['24400']
files = ['39706', '39725', '39776']
hgrepos = []
issue_num = 24450
keywords = ['patch']
message_count = 18.0
messages = ['245338', '245340', '245341', '245441', '245447', '245461', '245491', '245496', '245658', '245664', '245732', '245765', '245767', '246113', '246124', '246125', '246128', '246131']
nosy_count = 9.0
nosy_names = ['ncoghlan', 'scoder', 'larry', 'fwierzbicki', 'ethan.furman', 'python-dev', 'martin.panter', 'yselivanov', 'bennoleslie']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24450'
versions = ['Python 3.5', 'Python 3.6']

[bennoleslie]

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).

[bennoleslie]

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.

[vadmium]

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.

[1st1]

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.

[arigo]

No problem from PyPy.

[bennoleslie]

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

[ncoghlan]

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.

[scoder]

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?

[1st1]

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.

[ncoghlan]

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.

[vadmium]

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.