Author ncoghlan
Recipients Arfrever, eric.snow, gvanrossum, ncoghlan, skip.montanaro, vstinner, yselivanov
Date 2015-06-02.00:04:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1433203451.92.0.490258777482.issue24342@psf.upfronthosting.co.za>
In-reply-to
Content
Making sure I'm following the issue correctly here:

1. wrapper is a normal function, so there's no change for set_couroutine_wrapper() to detect anything might be amiss

2. any "async def" statement will call the registered coroutine wrapper to wrap the created function and turn it into a coroutine

3. this means any coroutine wrapper that directly or indirectly includes an "async def" statement will fail with RecursionError, without the problem being at all obvious

4. Yury's proposed patch effectively detects the use of "async def" inside a coroutine wrapper definition

I like the idea in principle, I don't like the error message in the current patch (since it only makes sense if you already understand the chain of reasoning above).

While it's a little verbose, I suggest an error like: "Coroutine wrapper %r attempted to recursively wrap %r", passing in the currently registered coroutine wrapper, and the code object we're attempting to wrap, respectively.

The latter repr gives the name, filename and line number of the offending code object, while the former should give the qualname of the registered wrapper.

The docs for set_coroutine_wrapper() should also be tweaked to note the constraint that the wrapper function cannot itself define new asynchronous functions (neither directly nor indirectly).
History
Date User Action Args
2015-06-02 00:04:12ncoghlansetrecipients: + ncoghlan, gvanrossum, skip.montanaro, vstinner, Arfrever, eric.snow, yselivanov
2015-06-02 00:04:11ncoghlansetmessageid: <1433203451.92.0.490258777482.issue24342@psf.upfronthosting.co.za>
2015-06-02 00:04:11ncoghlanlinkissue24342 messages
2015-06-02 00:04:11ncoghlancreate