On Thu, Oct 13, 2011 at 1:18 PM, Guido van Rossum email@example.com 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.
PS. An (unrelated) oddity with range and Decimal:
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'Decimal' object cannot be interpreted as an integer
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).