This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients chris.jerdonek, giampaolo.rodola, mbussonn, ncoghlan, njs, yselivanov
Date 2017-12-14.04:41:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1513226473.64.0.213398074469.issue30491@psf.upfronthosting.co.za>
In-reply-to
Content
> In any case, in my opinion, it doesn't matter.  `sys.set_coroutine_wrapper` controls a single thread-local setting, `sys.set_unawaited_coroutine_tracking` *also* controls a single thread-local setting.  Both of them have the exact same problem when there's more than one user of the API.  So we can't consider this as a strong argument in favour of the 'set_unawaited_coroutine_tracking' API.
[...]
> With that all in mind, my question is: have you guys tried to write a wrapper object in C for coroutines (or you can use Cython to get an idea)?

This is a fair point; we probably should try that :-).

I do think that there's more of a difference than you're realizing between set_coroutine_wrapper and set_unawaited_coroutine_tracking WRT their behavior around conflicts.

For set_unawaited_coroutine_tracking, the whole idea that makes it useful is if you have a single central piece of code that has a global view of what your program is doing, and can use that to figure out specific points where there should be no unawaited coroutines, plus has some strategy for reporting errors. For pytest-asyncio, it wants to check for these at the end of each test and then if found, fail that test. (Oh, I should mention that I did actually talk to the pytest-asyncio author about this and they do want to use it, this isn't hypothetical :-).) For trio, we have a more subtle rule like "check at each schedule point or catch-all exception handler, UNLESS it is in a task that is hosting asyncio code through our translation layer", and the reporting is more complicated too. But the point I want to make is that here, it's simpliy intrinsic in the design that whatever system is doing this has to have some pretty solid global knowledge, and it doesn't make sense to have two of these at once; no matter how we implemented this, two libraries trying to use it at the same time would necessarily need to coordinate somehow.

OTOH, for set_coroutine_wrapper, it's such a catch-all that it is plausible to have two different libraries that both want to use it at the same time, for two things that in principle don't conflict at all.

And not only is this plausible, it's what actually happens :-). If everyone uses set_coroutine_wrapper, then pytest-asyncio and asyncio will actually collide, and trio and asyncio will actually collide. But if we have set_unawaited_coroutine_tracking + set_coroutine_wrapper, then that's enough to prevent all the actual collisions we know about.
History
Date User Action Args
2017-12-14 04:41:13njssetrecipients: + njs, ncoghlan, giampaolo.rodola, chris.jerdonek, yselivanov, mbussonn
2017-12-14 04:41:13njssetmessageid: <1513226473.64.0.213398074469.issue30491@psf.upfronthosting.co.za>
2017-12-14 04:41:13njslinkissue30491 messages
2017-12-14 04:41:12njscreate