Mitchell Model <m...@acm.org> 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 <rep...@bugs.python.org>
<http://bugs.python.org/issue5953>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
