On Oct 12, 2011, at 12:36 PM, Sven Marnach wrote:
Steven D'Aprano schrieb am Do, 13. Okt 2011, um 04:33:49 +1100:
When implementing '==' and '!=' for range objects, it would be natural to implement the other comparison operators, too (lexicographically, as for all other sequence types).
I don't agree. Equality makes sense for ranges: two ranges are equal if they have the same start, stop and step values.
No, two ranges should be equal if they represent the same sequence, i.e. if they compare equal when converted to a list:
range(0) == range(4, 4, 4) range(5, 10, 3) == range(5, 11, 3) range(3, 6, 3) == range(3, 4)
Given that there are two reasonably valid interpretations of equality (i.e. produces-equivalent-sequences or the stronger condition, has-an-equal-start/stop/step-tuple), we should acknowledge the ambiguity and refuse the temptation to guess. I vote for not defining equality for range objects -- it's not really an important service anyway (you really can live without it).
Instead, let people explicitly compare the raw components, or if desired, compare components normalized by a slice:
range(2, 9, 2)[:]
range(2, 10, 2)