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