On 2015-04-29 5:13 AM, Greg Ewing wrote:
Yury Selivanov wrote:
3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines)
What about new 'async def' code called by existing code that expects to be able to use iter() or next() on the future objects it receives?
4. 'yield from' *only* raises an error if it yields a *coroutine with a CO_NATIVE_COROUTINE* from a regular generator.
Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'?
It would. But that's not a backwards compatibility issue. Everything will work in 3.5 without a single line change. If you want to use new coroutines - use them, everything will work too. If, however, during the refactoring you've missed several generator-based coroutines *and* they are not decorated with @coroutine - then yes, you will get a runtime error. I see absolutely no problem with that. It's a small price to pay for a better design. Yury