[Python-Dev] PEP 492: async/await in Python; version 4

Guido van Rossum guido at python.org
Fri May 1 01:49:21 CEST 2015

On Thu, Apr 30, 2015 at 4:24 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>

> Yury Selivanov wrote:
>> Well, using next() and iter() on coroutines in asyncio
>> code is something esoteric.  I can't even imagine
>> why you would want to do that.
> I'm talking about the fact that existing generator-
> based coroutines that aren't decorated with
> @coroutine won't be able to call new ones that use
> async def.
> This means that converting one body of code to the
> new style can force changes in other code that
> interacts with it.
> Maybe this is not considered a problem, but as long
> as it's true, I don't think it's accurate to claim
> "full backwards compatibility".

Greg, you seem to have an odd notion of "full backwards compatibility". The
term means that old code won't break. It doesn't imply that old and new
code can always seamlessly interact (that would be an impossibly high bar
for almost any change).

That said, interoperability between old code and new code is an area of
interest. But if the only thing that's standing between old code and new
code is the @coroutine decorator, things are looking pretty good -- that
decorator is already strongly required for coroutines intended for use with
the asyncio package, and older versions of the asyncio package also define
that decorator, so if there's old code out there that needs to be able to
call the new coroutines (by whatever name, e.g. async functions :-), adding
the @coroutine decorator to the old code doesn't look like too much of a

I assume there might be code out there that uses yield-from-based
coroutines but does not use the asyncio package, but I doubt there is much
code like that (I haven't seen much mention of yield-from outside its use
in asyncio). So I think the interop problem is mostly limited to
asyncio-using code that plays loose with the @coroutine decorator
requirement and now wants to work with the new async functions. That's easy
enough to address.

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150430/0676c0d4/attachment.html>

More information about the Python-Dev mailing list