Yes, that's why I was surprised. It's rare (isn't it?) to have str(a) == str(b) but a != b.  a not is b, sure, but a != b? Note also that list(range(n)) == list(range(n)). If the lists are equal and the strings are equal it's hard to see why the objects wouldn't be equal.

There are other things like range that define equality; for instance

        date.today() == datetime.date(2009, 5, 8)

Seems like ranges should define equals too.

However, I do understand the technical argument for saying not to use ranges except in prescribed places, largely for iteration.  Perhaps analagously, I discovered that webbrowser.open would open file URLs in their application on Macs (and perhaps Windows); when I suggested that behavior be added to the documentation of webbrowser what got added instead was a paragraph saying that although it might work it's neither supported nor portable. It could be that the right thing to do is instead of adding equality (though that would certainly be my preference) emphasize the statement that ranges have very little behavior, adding something like "in fact, two ranges are never equal" or something like that.

Either the documentation or the implementation should be changed -- it's just too much of a surprised to find that ranges aren't ever equal, especially when they were in Python 2.  (I'm still not claiming I can think of any logical reason for testing the equality of ranges. I stumbled on this while writing up a list of examples motivating pickling and trying to show for what kinds of values eval(str(value)) == value. I expected range to be one of them.

Here's another wrench, though: while a file is treated as a sequence of lines in for statements, I doubt anyone would want to ever compare files for equality. Possibly identity, to see if two open files are the same, but comparing the contents? That should be done under the program's control.

Sorry for the long-winded response. It wouldn't be as important if this were some corner of a little-used module, but range is really fundamental and it's better to get this right ASAP before people moving to Python 3 trip over it or rely on a behavior that might change in the future.

--

        --- Mitchell