Am 12.10.2011 19:33, schrieb Steven D'Aprano:

Aside:

I'm astonished to see that range objects have a count method! What's the purpose of that? Any value's count will either be 0 or 1

A method that works on any Sequence doesn't know that. Georg

On Wed, Oct 12, 2011 at 1:58 PM, Mark Dickinson wrote: ..

Should range(0, 10, 2) and range(0, 9, 2) be considered equal, or not?

I was going to ask the same question. I think ranges r1 and r2 should be considered equal iff list(r1) == list(r2). This is slightly harder to implement than just naively comparing (start, stop, step) tuples, but the advantage is that people won't run into surprises when they port 2.x code where result of range() is a list.

On Wed, Oct 12, 2011 at 1:58 PM, Mark Dickinson wrote:

...

I don't agree. Equality makes sense for ranges: two ranges are equal if

On Wed, Oct 12, 2011 at 6:33 PM, Steven D'Aprano wrote: they

...

have the same start, stop and step values.

Hmm. I'm not sure that it's that clear cut. The other possible definition is that two ranges are equal if they're equal as lists.

For equality and comparison, this should be the standard. range objects are sequences, and they should compare just like other sequences. If implemented at all, equality should be that they have the same items in the same order. If implemented at all, comparison should be lexicographic. It seems to me you'd need a really good reason to have behavior different from every other sequence. Mike

On Oct 12, 2011, at 12:36 PM, Sven Marnach wrote:

Steven D'Aprano schrieb am Do, 13. Okt 2011, um 04:33:49 +1100:

...

...

When implementing '==' and '!=' for range objects, it would be natural to implement the other comparison operators, too (lexicographically, as for all other sequence types).

I don't agree. Equality makes sense for ranges: two ranges are equal if they have the same start, stop and step values.

No, two ranges should be equal if they represent the same sequence, i.e. if they compare equal when converted to a list:

range(0) == range(4, 4, 4) range(5, 10, 3) == range(5, 11, 3) range(3, 6, 3) == range(3, 4)

Given that there are two reasonably valid interpretations of equality (i.e. produces-equivalent-sequences or the stronger condition, has-an-equal-start/stop/step-tuple), we should acknowledge the ambiguity and refuse the temptation to guess. I vote for not defining equality for range objects -- it's not really an important service anyway (you really can live without it). Instead, let people explicitly compare the raw components, or if desired, compare components normalized by a slice:

...

...

range(2, 9, 2)[:] range(2, 10, 2)

Raymond

Bruce Leban schrieb am Mi, 12. Okt 2011, um 11:30:17 -0700:

Other than unit testing, what are the use cases? If I was writing a unit test, I'd be inclined to be very explicit about what I meant r1 is r2 repr(r1) == repr(r2) list(r1) == list(r2)

Even with a useful '==' operator defined, you could still use 'r1 == r2' or 'r1 is r2', depending on the intended semnatics, just as with every other data type. You just wouldn't need to expand the range to a list. Comparing the representations doesn't ever seem useful, though. The only way to access the original start, stop and step values is by parsing the representation, and these values don't affect the behaviour of the range object in any other way. Moreover, they might even change implicitly: >>> range(5, 10, 3) range(5, 10, 3) >>> range(5, 10, 3)[:] range(5, 11, 3) I can't imagine any situation which I would like to consider the above two ranges different in. Cheers, Sven

On Wed, Oct 12, 2011 at 1:33 PM, Sven Marnach wrote:

Comparing the representations doesn't ever seem useful, though. The only way to access the original start, stop and step values is by parsing the representation, and these values don't affect the behaviour of the range object in any other way. Moreover, they might even change implicitly:

...

...

...

range(5, 10, 3) range(5, 10, 3) range(5, 10, 3)[:] range(5, 11, 3)

I can't imagine any situation which I would like to consider the above two ranges different in.

def test_copy_range(self): """Make sure that every time we call copy_range we get a new identical copy of the range.""" a = range(5, 10, 3) b = copy_range(a) c = copy_range(a) self.assert(a is not b) self.assert(a is not c) self.assert(b is not c) self.assert(repr(a) == repr(b)) self.assert(repr(a) == repr(c)) Anyway, my thought is that if you think this change should be made it would be helpful to have a use case other than unit tests as for those purposes, explicit list() or repr() is more clear and performance is not typically an issue. Why would you normally be comparing ranges at all? --- Bruce

I beg to differ with all those who want range(0, 10, 2) == range(0, 11, 2). After all the repr() shows the end point that was requested, not the end point after "normalization" (or whatever you'd call it) so the three parameters that went in should be considered state. OTOH range(10) == range(0, 10) == range(0, 10, 1). -- --Guido van Rossum (python.org/~guido)

On Wed, Oct 12, 2011 at 3:57 PM, Ethan Furman wrote:

Guido van Rossum wrote:

...

I beg to differ with all those who want range(0, 10, 2) == range(0, 11, 2).

I think practicality should beat purity here -- if the same results will be generated, then the ranges are the same and should be equal, no matter which exact parameters were used to create them.

Then we'd be forever stuck with not exporting the start/stop/step values. I'd much rather export those (like the slice() object does). (IOW I find the lack of exported start/stop/step values an omission, not a feature, and would like to fix that too.)

...

After all the repr() shows the end point that was requested, not the end point after "normalization" (or whatever you'd call it) so the three parameters that went in should be considered state.

OTOH range(10) == range(0, 10) == range(0, 10, 1).

Exactly.

Because their repr() is the same: "range(0, 10)", thus proving that the internal state is the same. For range objects, I believe that the internal state represents what theey really "mean", and the sequence of vallues generated by iterating merely follows. -- --Guido van Rossum (python.org/~guido)

On Wed, Oct 12, 2011 at 4:48 PM, Paul Moore wrote:

On 12 October 2011 22:12, Ethan Furman wrote:

...

Agreed -- comparing repr()s seems like a horrible way to do it.

As far as comparing for equality, there's an excellent answer on StackOverflow -- http://stackoverflow.com/questions/7740796

def ranges_equal(a, b):  return len(a)==len(b) and (len(a)==0 or a[0]==b[0] and a[-1]==b[-1])

While I'm agnostic on the question if whether range(0,9,2) and range(0,10,2) are the same, I'd point out that ranges_equal is straightforward to write and says they are equal. But if you're in the camp of saying they are not equal, you appear to have no way of determining that *except* by comparing reprs, as range objects don't seem to expose their start, step and end values as attributes - unless I've missed something.

...

...

...

r = range(0,10,2) dir(r) ['__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'count', 'index']

Rather than worrying about supporting equality operators on ranges, I'd suggest exposing the start, step and end attributes and then leaving people who want them to roll their own equality functions.

Unless I misunderstood, Guido is basically saying the same thing (the "exposing" part, that is). +1 on exposing start, step and end +1 on leaving it at that (unless it turns out to be a common case) -eric

Paul. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Wed, Oct 12, 2011 at 7:44 PM, Nick Coghlan wrote:

On Thu, Oct 13, 2011 at 11:45 AM, Eric Snow wrote:

...

Unless I misunderstood, Guido is basically saying the same thing (the "exposing" part, that is).

+1 on exposing start, step and end

+1

...

+1 on leaving it at that (unless it turns out to be a common case)

My reading is that Guido has reserved judgment on the second part for now. Options are:

- do nothing for 3.3 (+0 from me) - make sequence comparison the default (+1 from me) - make start/stop/step comparison the default (-1 from me)

Actually when I wrote that I was +1 on start/stop/step comparison and -1 on sequence (really: list) comparison. But I'd like to take a step back; we should really look at the use cases for comparing range objects. Since they don't return lists, you can't compare them to lists (or rather, they're always unequal). Because of this (and because it didn't work in 3.0, 3.1, 3.2) the proposed requirement that it should work the same as it did in Python 2 doesn't sway me. So what's the most useful comparison for range objects? When comparing non-empty ranges with step 1, I think we all agree. So we're left arguing about whether all empty ranges should be equal, and about whether non-empty ranges with step > 1 should compare equal if they have the same start, step and length (regardless of the exact value of stop). But why do we compare ranges? The first message in this thread (according to GMail) mentions unittests and suggests that it would be handy to check if two ranges are the same, but does not give a concrete example of such a unittest. The code example given uses list-wise comparison, but the use case is not elaborated further. Does anyone have an actual example of a unittest where being able to compare ranges would have been handy? Or of any other real-life example? Where it matter what happens if the range is empty or step is

1?

So, let me say I'm undecided (except on the desirability of an == test for ranges that's more useful than identity). FWIW, I don't think the argument from numeric comparisons carries directly. The reason numeric comparisons (across int, float and Decimal) ignore certain "state" of the value (like precision or type) is that that's how we want our numbers to work. The open question so far is: How do we want our ranges to work? My intuition is weak, but says: range(0) != range(1, 1) != range(1, 1, 2) and range(0, 10, 2) != range(0, 11, 2); all because the arguments (after filling in the defaults) are different, and those arguments can come out using the start, stop, step attributes (once we implement them :-).

If we do either of the latter, range.__hash__ should be updated accordingly (since 3.x range objects are currently hashable due to their reliance on the default identity comparison)

Sure. That's implied when __eq__ is updated (though a good reminder for whoever will produce the patch). (I'm also -1 on adding ordering comparisons; there's little disagreement on that issue.) PS. An (unrelated) oddity with range and Decimal:

...

...

range(Decimal(10)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'Decimal' object cannot be interpreted as an integer range(int(Decimal(10))) range(0, 10)

So int() knows something that range() doesn't. :-) -- --Guido van Rossum (python.org/~guido)

On Wed, Oct 12, 2011 at 9:53 PM, Nick Coghlan wrote:

On Thu, Oct 13, 2011 at 1:18 PM, Guido van Rossum wrote:

...

FWIW, I don't think the argument from numeric comparisons carries directly. The reason numeric comparisons (across int, float and Decimal) ignore certain "state" of the value (like precision or type) is that that's how we want our numbers to work.

The open question so far is: How do we want our ranges to work? My intuition is weak, but says: range(0) != range(1, 1) != range(1, 1, 2) and range(0, 10, 2) != range(0, 11, 2); all because the arguments (after filling in the defaults) are different, and those arguments can come out using the start, stop, step attributes (once we implement them :-).

Between this and Raymond's point about slicing permitting easy and cheap normalisation of endpoints, I'm convinced that, if we add direct comparison of ranges at all, then start/stop/step comparison is the way to go.

Thanks. Maybe I can nudge you a little more in the direction of my proposal by speaking about equivalence classes. A proper == function partitions the space of all objects into equivalence classes, which are non-overlapping sets such that all objects within one equivalence class are equal to each other, while no two objects in different classes are equal. (Let's leave NaN out of it for now; it does not have a "proper" == function.) There's a nice picture on this Wikipedia page: http://en.wikipedia.org/wiki/Equivalence_relation A trivial collection of equivalence classes is one where each object is in its own equivalence class. That's comparison-by-identity. It isn't very useful because we already have another operator that does the same partitioning. A more useful partitioning is the one which puts all range objects with the same start/stop/step triple into the same equivalence class. This is the one I (still) like best. Interestingly, the one that got the most votes so far is a proper "extension" of this one, in that equivalence according to equal start/stop/step triples implies equivalence according to this weaker definition. That's nice, because it means that there will probably be many use cases where either definition suffices (such as all use cases that only care about non-empty ranges with step==1). (Note: __hash__ needs to create equivalence classes that are proper extensions of those created by __eq__. In terms of the Wikipedia picture, an extension is allowed to merge some equivalence classes but not to split them.) BTW, I like Raymond's observation, and I agree that we should add slicing to range(), given that it already supports indexing; and slicing is a nice way to normalize the range. I just don't think that the status quo is better than either of the two proposed definitions for __eq__. Finally. Still waiting for actual use cases.

...

PS. An (unrelated) oddity with range and Decimal:

...

...

...

range(Decimal(10)) Traceback (most recent call last):  File "<stdin>", line 1, in <module> TypeError: 'Decimal' object cannot be interpreted as an integer range(int(Decimal(10))) range(0, 10)

So int() knows something that range() doesn't. :-)

Yeah, range() wants to keep floats far away, so it only checks __index__, not __int__. So Decimal gets handled the same way float does (i.e. not allowed directly, but permitted after explicit coercion to an integer).

Sorry, it all makes sense now. Please move on. Nothing to see here. :-) -- --Guido van Rossum (python.org/~guido)

Guido van Rossum wrote:

Thanks. Maybe I can nudge you a little more in the direction of my proposal by speaking about equivalence classes. A proper == function partitions the space of all objects into equivalence classes, which are non-overlapping sets such that all objects within one equivalence class are equal to each other, while no two objects in different classes are equal. (Let's leave NaN out of it for now; it does not have a "proper" == function.) There's a nice picture on this Wikipedia page: http://en.wikipedia.org/wiki/Equivalence_relation

Both proposals define proper equivalence classes -- there is no difference in this regard. In one proposal, equivalence is defined by identical behaviour, in the other equivalence is defined by identical parameters at creation time. I still strongly lean towards the definition based on identical behaviour. If it wasn't for this particular choice of representation of ranges, there wouldn't be any way to distinguish the objects range(3, 8, 3) and range(3, 9, 3) They would be the same in every respect. It feels entirely artificial to me to consider them as not equal just because we used different parameters to create them (and someone chose to include these parameters in the representation).

BTW, I like Raymond's observation, and I agree that we should add slicing to range(), given that it already supports indexing; and slicing is a nice way to normalize the range. I just don't think that the status quo is better than either of the two proposed definitions for __eq__.

range() already supports slicing, and it already does this: >>> r0 = range(3, 8, 3) >>> r1 = r[:] >>> r1 range(3, 9, 3) If we adopted equality based on start/stop/step, this would lead to the somewhat paradoxical situation that r0 != r0[:], in contrast to the behaviour of all other sequences in Python. Cheers, Sven

Guido van Rossum wrote:

Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'Decimal' object cannot be interpreted as an integer

...

...

...

range(int(Decimal(10)))

range(0, 10)

It refuses to work on floats, too, even if they happen to have integer values:

...

...

range(1.0, 10.0) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'float' object cannot be interpreted as an integer

If we think that's a good idea, presumably the same thing ought to apply to Decimals. Or are Decimals supposed to be more "exact" than floats somehow? -- Greg

On Thu, Oct 13, 2011 at 11:08 AM, Yuval Greenfield wrote:

+1 for refusing the temptation to guess.

Both equality definitions don't seem obvious or handy enough to be favorited by python. That is until some prevalent use cases are presented.

Ah, but the stricter equality definition (by start/stop/step) also refuses to guess! It doesn't consider range(0, 0) and range(1, 1) as equivalent because, indeed, it would have to guess. But it will consider range(1) == range(1) since everybody considers those equivalent so there's no guess-work involved. The identity-based __eq__ does nobody any good. -- --Guido van Rossum (python.org/~guido)

On Wed, 12 Oct 2011 20:18:50 -0700 Guido van Rossum wrote:

The open question so far is: How do we want our ranges to work? My intuition is weak, but says: range(0) != range(1, 1) != range(1, 1, 2) and range(0, 10, 2) != range(0, 11, 2); all because the arguments (after filling in the defaults) are different, and those arguments can come out using the start, stop, step attributes (once we implement them :-).

My intuition is contrary, but I think it comes down to: what is the use case for comparison ranges?

PS. An (unrelated) oddity with range and Decimal:

...

...

...

range(Decimal(10)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'Decimal' object cannot be interpreted as an integer range(int(Decimal(10))) range(0, 10)

So int() knows something that range() doesn't. :-)

Same as floats:

...

...

int(1.0) 1 range(1.0, 2, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'float' object cannot be interpreted as an integer

I thought it was by design? Regards Antoine.