On Mon, Feb 2, 2015 at 2:36 AM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Feb 01, 2015 at 10:18:33PM +0100, Todd wrote:
> On Feb 1, 2015 6:27 PM, "Steven D'Aprano" <steve@pearwood.info> wrote:

> > In other words, the similarity between slices and ranges is not as close
> > as you think.
> Fair enough.  But it doesn't really affect my proposal.  It would just be
> that this syntax only allows a subset of what you can do with slices.

It undercuts the justification for the proposal. Greg has also shown
that even with purely integer values, slices and ranges behave differently.

Slice objects are not a special case of ranges, and ranges are not a
special case of slice objects. They behave differently, have different
restrictions on their parameters, and different purposes. As far as I
can see, virtually the only similarity is the names of the three
parameters: start, stop, step.

You might object that there is an important similarity that I've missed:
slices (well, some slices) provide the same integer indexes as range
does. That is, for at least *some* combinations of integers a, b and c,
we have this invariant:

seq[a:b:c] == [seq[i] for i in range(a, b, c)]

But that's not a property of the slice object, that's a property of the
sequence! Slice object merely record the start, stop, step, which can be
arbitrary values in arbitrary order, and the sequence decides how to
interpret it.

The docs carefully don't describe the meaning of a slice object except
as a bundle of start, stop, step attributes:


That's because slice objects don't have any meaning except that which
the sequence chooses to give it. That is not true for range objects.

(By the way, the docs are wrong when they say slice objects have no
other explicit functionality: they also have an indices method.)

The above invariant is the conventional meaning, of course, and I'm not
suggesting that there are a lot of classes that ignore that conventional
meaning and do something else. But slice objects exist to be a simple
bundle of three attributes with arbitrary values, and ranges exist to be
a linear iterable of integers. The fact that sometimes they appear to
kind of almost overlap in meaning is incidental.

Then let's ignore the original justification, and say this is just a syntax for making ranges that is similar to, but not identical to, slices.