On Sat, Feb 20, 2016 at 12:57 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Feb 20, 2016 at 6:48 PM, Ian Kelly <ian.g.ke...@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.
--
https://mail.python.org/mailman/listinfo/python-list
