[Python-ideas] Membership of infinite iterators

[Serhiy Storchaka]

18.10.17 13:22, Nick Coghlan пише:
> 2.. These particular cases can be addressed locally using existing 
> protocols, so the chances of negative side effects are low

Only the particular case `count() in count()` can be addressed without 
breaking the following examples:

 >>> class C:
...     def __init__(self, count):
...         self.count = count
...     def __eq__(self, other):
...         print(self.count, other)
...         if not self.count:
...             return True
...         self.count -= 1
...         return False
...
 >>> import itertools
 >>> C(5) in itertools.count()
5 0
4 1
3 2
2 3
1 4
0 5
True
 >>> it = itertools.cycle([C(5)]); it in it
5 <itertools.cycle object at 0x7f65512d39b8>
4 <itertools.cycle object at 0x7f65512d39b8>
3 <itertools.cycle object at 0x7f65512d39b8>
2 <itertools.cycle object at 0x7f65512d39b8>
1 <itertools.cycle object at 0x7f65512d39b8>
0 <itertools.cycle object at 0x7f65512d39b8>
True
 >>> it = itertools.repeat(C(5)); it in it
5 repeat(<__main__.C object at 0x7f65512c5dc0>)
4 repeat(<__main__.C object at 0x7f65512c5dc0>)
3 repeat(<__main__.C object at 0x7f65512c5dc0>)
2 repeat(<__main__.C object at 0x7f65512c5dc0>)
1 repeat(<__main__.C object at 0x7f65512c5dc0>)
0 repeat(<__main__.C object at 0x7f65512c5dc0>)
True

> 3. The total amount of code involved is likely to be small (a dozen or 
> so lines of C, a similar number of lines of Python in the tests) in 
> well-isolated protocol functions, so the chances of introducing future 
> maintainability problems are low

It depends on what you want to achieve. Just prevent an infinity loop in 
`count() in count()`, or optimize `int in count()`, or optimize more 
special cases.

> 4. We have a potential contributor who is presumably offering to do the 
> work (if that's not the case, then the question is moot anyway until a 
> sufficiently interested volunteer turns up)

Maintaining is more than writing an initial code.

> If we were to do that, then we *could* make the solution to the reported 
> problem more general by having all builtin and standard library 
> operations that expect to be working with finite iterators (the 
> containment testing fallback, min, max, sum, any, all, functools.reduce, 
> etc) check for a length hint, even if they aren't actually 
> pre-allocating any memory.

This will add a significant overhead for relatively short (hundreds of 
items) sequences. I already did benchmarking for similar cases in the past.