[Python-ideas] Membership of infinite iterators

Nick Coghlan ncoghlan at gmail.com
Tue Oct 17 02:32:05 EDT 2017


On 16 October 2017 at 11:12, Jason Campbell <j_campbell7 at hotmail.com> wrote:

> I recently came across a bug where checking negative membership
> (__contains__ returns False) of an infinite iterator will freeze the
> program.
>
> It may seem a bit obvious, but you can check membership in range for
> example without iterating over the entire range.
>
As Terry noted, this is due to a semantic difference between range (compact
representation of a tuple of integers) and arbitrary iterators.

However, if we can avoid seemingly innocent code triggering an infinite
loop, that's probably a good thing.

> `int(1e100) in range(int(1e101))` on my machine takes about 1.5us
> `int(1e7) in itertools.count()` on my machine takes about 250ms (and gets
> worse quite quickly).
>
> Any membership test on the infinite iterators that is negative will freeze
> the program as stated earlier, which is odd to me.
>
The other relevant behavioural difference is that even a successful
membership test will consume the iterator up to that point.

> itertools.count can use the same math as range
>
+1, with the caveat that a successful containment test should still advance
the iterator to the point immediately after the requested element, just as
it does today (if people don't want that behaviour, they should be defining
a suitable finite range instead).

> itertools.cycle could use membership from the underlying iterable
>
Sort of - you'll still need to iterate through the underlying iterator at
least once in order to see all of the candidate elements. However, the
containment test could still be defined as running through the full cycle
at most once, such that you end up either at the point immediately after
the item or else back where you started (if the item wasn't found).

> itertools.repeat is even easier, just compare to the repeatable element
>
+1

So this sounds like a reasonable API UX improvement to me, but you'd need
to ensure that you don't inadvertently change the external behaviour of
*successful* containment tests.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171017/e23a7d6e/attachment-0001.html>


More information about the Python-ideas mailing list