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.
Ah, alright.
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.
Thanks,
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
