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