[issue5953] Add to "whats new": range(n) != range(n)

[Mitchell Model]

Mitchell Model  added the comment:

Ah. I see. I hadn't realized that. OK, I see how all the pieces fit together 
now. Thanks for all the explanations. They'll help me understand better what 
kinds of comments to make on the documentation.
-- 
-- 

--- Mitchell

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I should have been clearer.  It is not the function of whatsnew to show
all aspects of 2-to-3 changes.  It is enough to say that range() no
longer returns a list and instead returns what used to be an xrange()
object.  At that point, the job of full documentation of the function is
left to the main docs.  The whatsnew entries are supposed to be very
brief hints about where to look next.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

At some point, a person just needs to read the regular docs for range().

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Mitchell Model]

Mitchell Model  added the comment:

Sounds right. (1) I was raising the issue in case either the behavior was 
unintended or the documentation should mention it; (2) I realize that comparing 
ranges is strange; (3) I understand that range works in 3 the way xrange worked 
in 2, and that the what's new documentation says that range replaces xrange (4) 
you're point about ranges with steps clinches the issue, I think -- certainly 
equality of ranges should not have to compute the range -- they should be 
thought of as generators (and maybe documented as such -- for all I know, since 
I haven't looked, they are implemented that way); (5) I agree that range 
behaves like an iterator -- its documentation at the introduction to sequence 
tyhpes even points out that in, not in, max, and min are inefficient (6) the 
specific documentation for range explicitly states that they have very little 
behavior supporting only indexing, iteration, and len().

Your comments were very helpful in explicitly laying out the issues regarding 
implementing equality and the relative unimportance of the change in behavior, 
and I now have the explanation I wanted.

The only thing that still makes me uncomfortable is that it wouldn't be such a 
big deal to point out in the 3.0 "what's new" document where the change to 
range is mentioned in a bullet that range supports only indexing, iteration, 
and len, and that operations such as in and not in and functions such as max 
and min are inefficient because, except in when true, they require iterating 
over the entire range. Since these are specified in the actual documentation of 
range I believe they should be added to the what's new, where the change to 
range is described. I agree that what things don't do should rarely be 
documented, but if they no longer do something that they used to do, that 
should go in the "what's new" document -- at least in the form of an explicit 
list of what they do do. The only argument I can see against doing that is that 
the document says that "range() now behaves like xrange() used to behave", but 
I don't feel that is sufficiently explicit for people who have used
  range extensively but never or rarely xrange or who don't think about its 
implications. Maybe the "what's new" should just say that range() acts like an 
iterator.

All in all I'm satisfied and appreciative, except that I'm still left with the 
feeling that something about range() should be added to the 3.0 "what's new".
-- 
-- 

--- Mitchell

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Am inclined to reject this request.  We shouldn't get in the habit of
documenting what functions don't do.  In the past, no one seemed to have
any trouble with xrange() not being comparable to itself.  In the
present, there are many functions that return iterators instead of
lists, so the expectation for comparability will be even lower.

The main problem with anti-documentation is that bringing up the topic
can plant it in a reader's memory in a confusing way, "I think I read
something about ranges and comparability ...".  IOW, just talking about
it makes it more likely that someone will be led to making a fallacious
assumption.

Likewise, I don't want to put in a recommendation about comparing the
repr() of ranges either.  The problem is that the (start,stop,step)
tuples can differ but the ranges can be the same:

   >>> args1 = 0, 101, 5
   >>> args2 = 0, 102, 5
   >>> args1 == args2
   False
   >>> list(range(*args1)) == list(range(*args2))
   True

Also, I'm not worried about this one because comparing the output of
range() was not a common thing to do even in Py2.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Mitchell Model wrote:
> Mitchell Model  added the comment:
> 
> Sorry -- I did notice in the copies sent to me of my replies to
> bugs.python.org that there was HTML, but I can't  figure out why. I
> didn't use any style text in the message nor in my signature. I
> thought my email program only sent HTML when there was some styled
> text in the message. I just changed a setting that might fix this --
> please tell me if you are seeing HTML in this.

No, looks great.  I believe for most (all?) mailers, '[x] sent html' 
*always* sends html, even if not 'needed'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Mitchell Model]

Mitchell Model  added the comment:

Sorry -- I did notice in the copies sent to me of my replies to bugs.python.org 
that there was HTML, but I can't  figure out why. I didn't use any style text 
in the message nor in my signature. I thought my email program only sent HTML 
when there was some styled text in the message. I just changed a setting that 
might fix this -- please tell me if you are seeing HTML in this.
-- 
-- 

--- Mitchell

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Please don't post html.  For whatever reason, it displayed as
hard-to-read marked-up html text when emailed (and my reader does
usually display html messages properly).  Perhaps the email mime-type
was wrong even though it looks ok in Firefox.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Mitchell Model]

Mitchell Model  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 
<http://bugs.python.org/issue5953>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 -->Re: [issue5953] Add to "whats new":
range(n) != range(n)
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.
-- 

-- 

    --- 

[issue5953] Add to "whats new": range(n) != range(n)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Alternatively, range objects could have a .__eq__ method that compares
the (hidden) start, stop, and step attributes used to print the
representations.

As a workaround, str(r1)==str(rs) will work as expected.

--
nosy: +tjreedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5953] Add to "whats new": range(n) != range(n)

[Mitchell Model]

New submission from Mitchell Model :

I just discovered to my (deep) surprise that
range(n) != range(n)
I think that's worth including in the what's new document.
I realize that the document essentially says that in python 3 range
behaves the way xrange did in python 2 and that ranges have very little
behavior, but surely the lack of equality of two ranges whose string
representations are equal is enough of a surprise and difference from
python 2 to be worth an explicit comment. (Or maybe no-one ever compares
ranges? They are just for iteration? Even that should be said
explicitly. This is one of those things that I'm sure expert developers
look at and think is obvious but might trip up ordinary users.)

--
assignee: georg.brandl
components: Documentation
messages: 87357
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Add to "whats new": range(n) != range(n)
versions: Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com