[Python-ideas] Expose `itertools.count.start` and implement `itertools.count.__eq__` based on it, like `range`.

[Terry Reedy]

On 6/7/2014 4:33 PM, Antony Lee wrote:
> I agree that "range(start=x)" is awkward due to the unusual argument
> handling of "range", and you are also correct that I should have said
> "an iterable for which iter(range(x, None, step)) behaves as count(n,
> step)".

> I don't see an issue with len and negative indexing raising ValueError
> and IndexError, respectively.  After all, a negative index on an
> infinite sequence is just as undefined.

The issue is doing that with range, which is defined to a sequence, and 
is registered as a collections.abc.Sequence. Break the promise of that 
definition, break code, people scream. Many functions properly require a 
sequence rather than just any iterable.

from collections.abc import Sequence
def cross(seq):
     if not issubclass(seq, Sequence):
         raise TypeError("%x is not a collections.abc.Sequence" % type(seq))
     for first in seq:
         for second in seq:
             yield (first, second)

There is another issue with merely extending range -- its weird 
signature. Range(10) stops at 10; count(10) begins at 10. The signature 
of an iterable based on count should be based on count, not range.

Semi-infinite-sequence could be a well-defined category of classes. But 
it should start outside of the stdlib.  It could be fun, and have niche 
uses, like teaching.  But like Nick, I am dubious that it would add 
enough to beyond having infinite iterators to warrant being in the 
stdlib.  In any case, that would need to be proven with field experience.

-- 
Terry Jan Reedy