I have a use case now: switching slice.indices() to return a range object instead of a tuple. That heavily favours the 'behave like a sequence' approach.
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Oct 15, 2011 3:08 AM, "Nick Coghlan" <firstname.lastname@example.org> wrote:
> On Sat, Oct 15, 2011 at 5:52 AM, Alexander Belopolsky
> <email@example.com> wrote:
> > On Fri, Oct 14, 2011 at 1:23 PM, Guido van Rossum <firstname.lastname@example.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:
> 1. Identity based (status quo): each range object is equal only to itself
> 2. 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.