Cannot step through asynchronous iterator manually

[Kevin Conway]

> Any particular reason not to use the classic sentinel object model?

None that I can remember. I would use the sentinel pattern if I were
writing it again today.

> Also curious is that you raise a new StopAsyncIteration from the original
one, rather than just reraising the original. I assume there's a reason for
that, but it doesn't have a comment.

I think I was just playing around with the new syntax.

I also just noticed that there is an inconsistent use of the terms iterator
and iterable in the docstring and variable names. The function looks much
improved after updates: https://bpaste.net/show/14292d2b4070. Thanks for
calling that out.

Note to self: Review old code before copy/pasta into the mail list.

On Sat, Jan 30, 2016 at 6:57 AM Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Jan 30, 2016 at 11:35 PM, Kevin Conway
> <kevinjacobconway at gmail.com> wrote:
> > To address the original question, I don't believe a next() equivalent for
> > async iterables has been added to the standard library yet. Here's an
> > implementation from one of my projects that I use to manually get the
> next
> > value: https://bpaste.net/show/e4bd209fc067. It exposes the same
> interface
> > as the synchronous next(). Usage:
> >
> >     await anext(some_async_iterator)
> >
> > Ultimately, it's a fancy wrapper around the original snippet of 'await
> > iterator.__anext__()'.
>
> Curious idiom for the one-or-two-arg situation. Any particular reason
> not to use the classic sentinel object model?
>
> _SENTINEL = object()
> async def anext(iterable, default=_SENTINEL):
>     ...
>         if default is not _SENTINEL:
>             return default
>
> Or if you want to avoid that, at least take iterable as a fixed arg:
>
> async def anext(iterable, *default):
>     if len(default) > 1: TypeError
>     ...
>         if default: return default[0]
>
> Also curious is that you raise a new StopAsyncIteration from the
> original one, rather than just reraising the original. I assume
> there's a reason for that, but it doesn't have a comment.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>