Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: How the heck does async/await work in Python 3.5
Date: Sat, 20 Feb 2016 01:14:48 -0700
Lines: 41
Message-ID: <mailman.15.1455956130.13884.python-list@python.org>
References: <mailman.224.1455746935.22075.python-list@python.org> <56c7d145$0$1597$c3e8da3$5496439d@news.astraweb.com> <9d968a2e-f23c-4c93-979d-43dfa610c343@googlegroups.com> <CALwzidnVrNmhbRhkoiCkwZbqw+7h8gd_TY5HLUMNs1ROcHzQhQ@mail.gmail.com> <CAPTjJmoFiPtoo7oNopUqsrsQJhZWySA_hGEXbuXbQxKgmPh44A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <CAPTjJmoFiPtoo7oNopUqsrsQJhZWySA_hGEXbuXbQxKgmPh44A@mail.gmail.com>
Precedence: list
Xref: csiph.com comp.lang.python:103249

On Sat, Feb 20, 2016 at 12:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Feb 20, 2016 at 6:48 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> As another point that happens to be fresh in my mind, awaiting a
>> Future on which an exception gets set is supposed to propagate the
>> exception. I recently found that this breaks if the exception in
>> question happens to be StopIteration (granted not one that should
>> generally be allowed to propagate anyway, but that's a separate
>> discussion) for the simple reason that raising StopIteration in a
>> generator is equivalent to returning None.
>
> Solved by PEP 479. Use "from __future__ import generator_stop" to save
> yourself the pain.

Nope.

py> from __future__ import generator_stop
py> import asyncio
py> async def test_coro():
...     fut = asyncio.Future()
...     fut.set_exception(StopIteration())
...     print('received %r' % await fut)
...
py> list(test_coro().__await__())
received None
[]

I think because __future__ imports are per-file, and
asyncio.Future.__iter__ is defined in a file outside my control that
doesn't have the __future__ import.

I suppose that when the generator_stop behavior becomes standard then
it will work, but still that will just cause a RuntimeError to
propagate instead of the desired StopIteration.

It's not really that big a deal since there is a code smell to it, but
it's surprising since intuitively StopIteration should have no special
meaning to a PEP 492 coroutine (it's not an iterator, wink wink, nudge
nudge), and the thing being awaited is a Future, which also doesn't
intuitively look like an iterator. Note that if you just call
Future.result(), then the exception propagates as expected; it's just
awaiting it that doesn't work.