[Python-ideas] Implement comparison operators for range objects

[Nick Coghlan]

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 8:58 PM, "Yuval Greenfield" <ubershmekel at gmail.com> wrote:

>
> On Oct 15, 2011 3:08 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> >
> > On Sat, Oct 15, 2011 at 5:52 AM, Alexander Belopolsky
> > <alexander.belopolsky at gmail.com> wrote:
> > > On Fri, Oct 14, 2011 at 1:23 PM, Guido van Rossum <guido at 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:
> >
> > 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.
>
> --Yuval
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111016/33e4168d/attachment.html>