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 yselivanov
Recipients Ben.Darnell, gvanrossum, ncoghlan, scoder, vstinner, yselivanov
Date 2015-06-09.16:45:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1433868336.65.0.282673856642.issue24400@psf.upfronthosting.co.za>
In-reply-to
Content
Please see the attached patch.

Couple of notes:

1. It adds a new type: 'coroutine' (PyCoro_Type).  The implementation is still heavily based on generators, there are no changes there.

2. Unfortunately, a new opcode needs to be added - GET_YIELD_FROM_ITER. The idea is that YIELD_FROM from generators decorated with @coroutine must accept
'async def' coroutines.  But 'for' loops (iter(), etc) must throw an error on them.  On the bright side, because of this new opcode, the ceval code became much easier to follow.

3. This change removes the need to use __instancecheck__ for 'async def' coroutines.  BUT, it's still there for generators decorated with @coroutine.  Stefan suggests to wrap generators in a thin wrapper with __await__ method, but I don't like this idea -- it will inevitably make existing asyncio code slower in 3.5; I'm -0.5 on this idea.

4. While this patch addresses initial request from Ben only partially (generator-based coroutines still require __instancecheck__), I believe that it's still a good idea to separate 'async def' coroutines & generators in 3.5.  I'm fully confident that we shouldn't have any issues with that.
History
Date User Action Args
2015-06-09 16:45:37yselivanovsetrecipients: + yselivanov, gvanrossum, ncoghlan, scoder, vstinner, Ben.Darnell
2015-06-09 16:45:36yselivanovsetmessageid: <1433868336.65.0.282673856642.issue24400@psf.upfronthosting.co.za>
2015-06-09 16:45:36yselivanovlinkissue24400 messages
2015-06-09 16:45:36yselivanovcreate