RetroSearch Browse

Fri May 1 01:40:26 CEST 2015 · http://mail.python.org/pipermail/python-dev/2015-May/139730.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2015-May/139730.html below:

[Python-Dev] PEP 492: async/await in Python; version 4