[issue5953] Add to "whats new": range(n) != range(n)
Mitchell Model
report at bugs.python.org
Fri May 8 21:34:28 CEST 2009
Mitchell Model <mlm at acm.org> added the comment:
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
----------
Added file: http://bugs.python.org/file13933/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________
-------------- next part --------------
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [issue5953] Add to "whats new":
range(n) != range(n)</title></head><body>
<div>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.</div>
<div><br></div>
<div>There are other things like range that define equality; for
instance</div>
<div><x-tab>
</x-tab>date.today() == datetime.date(2009, 5, 8)</div>
<div>Seems like ranges should define equals too.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><tt>-- </tt></div>
<div>-- <br>
<br>
--- Mitchell</div>
</body>
</html>
More information about the Python-bugs-list
mailing list