On Oct 15, 2011 3:08 AM, "Nick Coghlan" ncoghlan@gmail.com wrote:
On Sat, Oct 15, 2011 at 5:52 AM, Alexander Belopolsky alexander.belopolsky@gmail.com wrote:
On Fri, Oct 14, 2011 at 1:23 PM, Guido van Rossum guido@python.org
wrote:
..
- add read-only attributes .start, .step, .stop
- add slicing such that it normalizes .stop to .start + the right
multiple of .step
- add __eq__ and __hash__ which compare by .start, .step, .stop
-1
I did not see a clear statement of a use-case for any of these features. I could imagine convenience of __eq__ for those used to range() returning a list, but comparing by .start, .step, .stop would destroy this convenience. If you need an object with .start, .step, .stop, we already have the slice object. NumPy has some functionality to create a regular sequence from a slice object. I don't see why someone would need a __hash__. If you want to key some values by ranges, just use 3-tuples instead.
The key point here is that you can *already* invoke '==' and 'hash()' on 3.x ranges - they just have useless identity based semantics. The proposal is merely to make the semantics less pointless for something you can already do.
It's also a potential step in the ongoing evolution of ranges towards being more like an optimised tuple of integers (but see my final comment to Guido below).
The question is how to define the equivalence classes. There are 3 possible sets of equivalence classes available. In order of increasing size, they are:
- Identity based (status quo): each range object is equal only to itself
- Definition based: range objects are equal if their start, stop and
step values are equal 3. Behaviour based: range objects are equal if they produce the same sequence of values when iterated over
Option 4 would be to kill the __eq__ method for range objects.
I think 3 or 4 are the best alternatives. Since we still haven't seen any use cases, option #4 seems like the bikeshed stopper.
--Yuval