PEP 424 allows iterators to optionally offer a hint as to how long they will be: https://www.python.org/dev/peps/pep-0424/ Unfortunately, there's no good way for an iterator to report that it is infinitely long. Consequently, even those which are known to be infinite report finite lengths: py> from itertools import count py> from operator import length_hint py> infinite = count() py> length_hint(infinite) 0 This wastes the opportunity to fail fast on operations which cannot possibly succeed, e.g. list(count()) must eventually fail with MemoryError. Or worse: if the OS starts thrashing trying to meet the memory requests, you can lock up the computer. I propose that we: (1) extend the __length_hint__ protocol to allow iterators to report that they are infinite; (2) and recommend that consumers of iterators (such as list) that require finite input should fail fast in the event of an infinite iterator. Four possible ways that __length_hint__ and operator.length_hint might signal an infinite iterator: (a) return a negative value such as -1 (this is currently an error); (b) return some special sentinel value; (c) take the convention that returning sys.maxint means infinity; (d) raise an exception. The advantage of (d) is that consumers of check __length_hint__ don't need to do anything special to fail fast on infinite iterators: py> class Thing: ... def __length_hint__(self): ... raise ValueError('infinite') ... def __iter__(self): ... return count() ... py> x = Thing() py> list(x) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in __length_hint__ ValueError: infinite but if they can cope with such, they can explicitly catch the exception. Thoughts? -- Steve