On Sun, Oct 16, 2011 at 3:21 AM, Alexander Belopolsky alexander.belopolsky@gmail.com wrote:
On Sat, Oct 15, 2011 at 10:28 AM, Nick Coghlan ncoghlan@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.