On 2015-04-30 7:24 PM, Greg Ewing 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.
You quoted this:
3. CO_NATIVE_COROUTINE flag. This enables us to disable __iter__ and __next__ on native coroutines while maintaining full backwards compatibility.
I wrote "full backwards compatibility" for that particular point #3 -- existing @asyncio.coroutines will have __iter__ and __next__ working just fine.
Sorry if this was misleading.
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".
I covered this in point #4. I also touched this in https://www.python.org/dev/peps/pep-0492/#migration-strategy
I'm still waiting for feedback on this from Guido. If he decides to go with RuntimeWarnings, then it's 100% backwards compatible. If we keep TypeErrors -- then *existing code will work on 3.5*, but something *might* break during adopting new syntax. I'll update the Backwards Compatibility section.