Nick Coghlan schrieb am Do, 13. Okt 2011, um 11:43:53 +1000:
I'll weigh in on the "compare like a sequence" side, even if the specific range definitions are different. It's the way range comparisons work in Python 2 and I'd like range() objects to be as close to a computationally defined immutable list as we can get them. It may even make sense to make them hashable in those terms.
The current interface of ranges is that of a sequence and nothing more. The only place where the original parameters that were used to create the sequence pop up is in its representation. Giving those parameters more weight seems a bit like remembering the list coomprehension that was used to create a list and take this into account when comparing lists (of course I'm exaggerating here to make a point).
But not exposing start/stop/step is a definite oversight - I actually thought we *did* expose them, but I was thinking of slice objects. With those attributes exposed, anyone that wants a more restrictive form of equality can easily implement it for themselves.
The current implementation of range objects could be both made considerably shorter and sped up a bit by normalising the parameters right from the start. I'd argue that doing so would be a good idea even when start, stop and step are exposed. It would make clear what is happening and remove any ambiguity as to the semantics of range objects in general and comparison of range objects in particular. (A simple implementation is more often than not a good indication for having arrived at the right notions.)
Note that using '[:]' does not completely normalise a range object. It only normalises the stop parameter.
Cheers, Sven