On Thu, Apr 30, 2015 at 4:24 PM, Greg Ewing firstname.lastname@example.org wrote:
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 burden.
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.