[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Koos Zevenhoven added the comment: That said, I agree with Antoine that being able to Ctrl-C would be the most useful of these fixes. But it seems clear that people are experiencing these issues differently (if at all). -- ___ Python tracker

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Koos Zevenhoven added the comment: I'd say there are three different problems related to this: (1) The inability of infinite iterators/iterables to say anything about their length (2) The inability to interrupt C-level loops (3) The horrible consequences of things like list(itertools.count(

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Erik Bray added the comment: > Thinking about the generator-iterator case a bit more, "False" would be a bad > default for that. Allowing "NotImplemented" to indicate the ambiguous "Might > be finite, might be infinite" state, and using that as the default for > generator-iterators, would pr

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Antoine Pitrou added the comment: I think being able to handle Ctrl-C would be the right solution here. Not handling Ctrl-C is a problem also for very long but non-infinite iterators. -- ___ Python tracker ___

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Nick Coghlan added the comment: If C level iterator implementations in the standard library natively handled Ctrl-C (to cope with naive third party C level iterator consumers), and so did C level iterator consumers in the standard library (to cope with with naive third party C level iterator

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Serhiy Storchaka added the comment: > Infinite is just a special case of "bigger or slower than convenient". I have the same opinion. -- ___ Python tracker ___ __

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Raymond Hettinger added the comment: After more thought, I'm no longer convinced this would be useful. Infinite is just a special case of "bigger or slower than convenient". In a way, min(count()) is no more interesting than min(range(1_000_000_000_000)) or min(slow_data_source()). --

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Antoine Pitrou added the comment: Downside of __infinite_iterator__: another additional attribute to look up, and its functionality overlaps with __length_hint__. I'd rather have a special return value for __length_hint__ (e.g. -1, -2, whatever). -- nosy: +pitrou __

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Nick Coghlan added the comment: Thinking about the generator-iterator case a bit more, "False" would be a bad default for that. Allowing "NotImplemented" to indicate the ambiguous "Might be finite, might be infinite" state, and using that as the default for generator-iterators, would probabl

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Nick Coghlan added the comment: (I've updated the issue title to state the design requirement, rather than one potential solution to the design requirement) I like the declarative `__infinite_iterator__` suggestion, as that's: 1. really easy to implement when defining a custom iterator type