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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4