[Python-ideas] Implement comparison operators for range objects

[Nick Coghlan]

On Sun, Oct 16, 2011 at 3:21 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Sat, Oct 15, 2011 at 10:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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.
>
> I like the idea, but why is this a use-case for range.__eq__ or range.__hash__?
>
> I like the idea not because it will lead to any optimisation.
> Slice.indices() does not return a tuple containing all indices in a
> slice.  The result is always a 3-tuple containing normalized start,
> stop, and step.  A range object cannot be more efficient than a
> 3-tuple.
>
> I still like the idea because it would make indices() return what the
> name suggests - the sequence of indices selectable by the slice.
>

Ah, you're quite correct - it only seemed like a use case for equality
because I was thinking slice.indices() returned an actual tuple of
indices, in which case range() would need to behave like a tuple of
integers for compatibility reasons.

I forgot that the expression to get the actual indices (rather than
the start/stop/step values) is
"range(*slice_obj.indices(len(container))". Now that we have full
memory efficient range objects, perhaps slice objects should grow a
more direct API, along the lines of
"slice_obj.make_range(len(container))"

Still, "act roughly like a memory efficient tuple of integers" remains
a useful design guideline for 3.x range behaviour.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia