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.