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

[Steven D'Aprano]

On Thu, May 15, 2014 at 01:02:56PM -0700, Ram Rachum wrote:

> I suggest exposing `itertools.count.start` and implementing 
> `itertools.count.__eq__` based on it. This'll provide the same benefits 
> that `range` got by exposing `range.start` and allowing `range.__eq__`.

What benefits are those? Under what circumstances have you compared two 
range objects or checked their start? That's a serious question -- I 
don't recall ever wanting to compare range objects for equality.

The iterator protocol is intentionally very simple, and I think that is 
a good thing. Adding complexity to one specific standard iterator 
without a good, solid use-case does not strike me as a good idea. But 
even if you have a good use-case, I don't think the concept of equality 
for count objects is very well defined. Consider:

from itertools import count
a = count(1)
b = count(1)
_ = next(b); _ = next(b)
c = count(3)


a.start and b.start are the same, so one might argue that a and b should 
compare equal. But next(a) and next(b) are different, so one might 
equally argue that a and b should compare unequal.

Likewise b.start and c.start are different, but next(b) and next(c) 
return the same value, so one might expect b and c to be both equal and 
unequal.

I think, whichever definition of equality you pick, people will be 
surprised by it fifty percent of the time.



-- 
Steven