RetroSearch Browse

Wed Apr 29 11:13:01 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-April/139617.html

Yury Selivanov wrote:
> 
> On 2015-04-28 11:59 PM, Greg wrote:
> 
>> On 29/04/2015 9:49 a.m., Guido van Rossum wrote:
>>
>>>     *But* every generator-based coroutine *must* be
>>>     decorated with `asyncio.coroutine()`.  This is
>>>     potentially a backwards incompatible change.
>>>
>>> See below. I worry about backward compatibility. A lot. Are you saying
>>> that asycio-based code that doesn't use @coroutine will break in 3.5?
>>
>> That seems unavoidable if the goal is for 'await' to only
>> work on generators that are intended to implement coroutines,
> 
> Not sure what you mean by "unavoidable".

Guido is worried about existing asyncio-based code that
doesn't always decorate its generators with @coroutine.

If I understand correctly, if you have

    @coroutine
    def coro1():
       yield from coro2()

    def coro2():
       yield from ...

then coro1() would no longer work. In other words,
some currently legitimate asyncio-based code will break
under PEP 492 even if it doesn't use any PEP 492 features.

What you seem to be trying to do here is catch the
mistake of using a non-coroutine iterator as if it
were a coroutine. By "unavoidable" I mean I can't see
a way to achieve that in all possible permutations
without giving up some backward compatibility.

-- 
Greg

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

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/139617.html below:

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