[Python-ideas] Expose `itertools.count.start` and implement `itertools.count.__eq__` based on it, like `range`.
Steven D'Aprano
steve at pearwood.info
Fri May 16 01:35:36 CEST 2014
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
More information about the Python-ideas
mailing list