Re: [Python-Dev] range objects in 3.x
Benjamin Peterson wrote:
2011/9/23 Ethan Furman
: Follow-up question: since the original range returned lists, and comparisons do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range. I'm -0 with a decision to not have range be orderable; but I understand there are bigger fish to fry. :) My original concern was that the comparison methods were there at all, but looking around I see object has them, so it makes sense to me now. I had thought I would have to implement them if I went ahead with an frange (for floats).
I note that it does implement __contains__, __getitem__, count, and index in the same way that list does.
That's because it implements the Sequence ABC.
So the question becomes, Why does it implement the Sequence ABC? Because the original range returned a list and those operations made sense? ~Ethan~
2011/9/23 Ethan Furman
Benjamin Peterson wrote:
2011/9/23 Ethan Furman
: Follow-up question: since the original range returned lists, and comparisons do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range.
range comparisons in 2.x have no functionality.
I note that it does implement __contains__, __getitem__, count, and index in the same way that list does.
That's because it implements the Sequence ABC.
So the question becomes, Why does it implement the Sequence ABC? Because the original range returned a list and those operations made sense?
I'm not sure what the history is. -- Regards, Benjamin
Benjamin Peterson wrote:
2011/9/23 Ethan Furman
: Benjamin Peterson wrote:
2011/9/23 Ethan Furman
: Follow-up question: since the original range returned lists, and comparisons do make sense for lists, should the new range also implement them?
What would be the use-case? The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range.
range comparisons in 2.x have no functionality.
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> r1 = range(10) --> r2 = range(0, 20, 2) --> r3 = range(10) --> r1 == r3 True --> r1 < r2 True --> r3 > r2 False Yes, I realize this is because range returned a list in 2.x. However, aren't __contains__, __getitem__, count, and index implemented in 3.x range because 2.x range returned lists? ~Ethan~
Yes, I realize this is because range returned a list in 2.x. However, aren't __contains__, __getitem__, count, and index implemented in 3.x range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an obvious meaning. "Is 30 in the range from 10 to 40?" is something that everybody will answer the same way. "What is the fifth element of the range from 10 to 40?" may not have such a universal meaning, but people familiar with the mathematical concept of an interval can readily guess the answer (except that they may wonder whether to start counting at 0 or 1). "Is the range from 5 to 100 larger than the range from 10 to 100?" is something that most people would answer as "yes" (I believe), yet py> range(5,100) > range(10,100) False Regards, Martin
Martin v. Löwis wrote:
Yes, I realize this is because range returned a list in 2.x. However, aren't __contains__, __getitem__, count, and index implemented in 3.x range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an obvious meaning. "Is 30 in the range from 10 to 40?" is something that everybody will answer the same way. "What is the fifth element of the range from 10 to 40?" may not have such a universal meaning, but people familiar with the mathematical concept of an interval can readily guess the answer (except that they may wonder whether to start counting at 0 or 1).
"Is the range from 5 to 100 larger than the range from 10 to 100?" is something that most people would answer as "yes" (I believe), yet
py> range(5,100) > range(10,100) False
Thanks, Martin! I can see where there could be many interpretations about the meaning of less-than and greater-than with regards to range. ~Ethan~
On Fri, Sep 23, 2011 at 1:23 PM, Ethan Furman
The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range.
I'm -0 with a decision to not have range be orderable; but I understand there are bigger fish to fry. :)
I don't believe there's a valid use case for ordering ranges. As for backwards compatibility, apparently nobody cares or we would've heard about it.
My original concern was that the comparison methods were there at all, but looking around I see object has them, so it makes sense to me now. I had thought I would have to implement them if I went ahead with an frange (for floats).
[...]> So the question becomes, Why does it implement the Sequence ABC? Because the
original range returned a list and those operations made sense?
Because all operations on Sequence make sense: you can iterate over a range, it has a definite number of items, and so on; all other sequence operations can be derived from that easily (and in fact they almost all be done in O(1) time). -- --Guido van Rossum (python.org/~guido)
Le Fri, 23 Sep 2011 13:23:26 -0700,
Ethan Furman
So the question becomes, Why does it implement the Sequence ABC?
Because these operations are trivial to implement and it would be suboptimal to have to instantiate the full list to run them?
Ethan Furman wrote:
The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range.
Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't see any loss of functionality there. Comparing range objects directly in 3.x is like comparing xrange objects in 2.x, and there the comparison was arbitrary -- it did *not* compare them like their corresponding lists: Python 2.7 (r27:82500, Oct 15 2010, 21:14:33) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information.
a = xrange(5) b = xrange(5) a > b True
-- Greg
participants (6)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Benjamin Peterson
-
Ethan Furman
-
Greg Ewing
-
Guido van Rossum