From: Colin W. on
On 16-Dec-09 19:23 PM, Gregory Ewing wrote:
> Terry Reedy wrote:
>> So it would be MUCH more useful if that notation created a range object.
>>
>> for i in [1:n]: ...
>>
>> So I would oppose the slice proposal in favor of a range proposal.
>
> Another possibility would be to unify range and slice
> objects so that they're actually the same thing. Then
> the same notation could be used for both purposes.
>
This would be good if the increment could also be handled.

Terry Reedy suggested:- for i in [1:n]: ...

Are the brackets really needed?

Colin W.
From: Nobody on
On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:

> Many more people uses range objects (xrange in 2.x). A range object has
> the same info as a slice object *plus* it is iterable.

This isn't quite true, as a range cannot have a stop value of None, i.e.
you can't represent [n:] or [:] etc as a range. Similarly for using
negative stop values for indices relative to the end of the sequence being
sliced.

Also, aside from the semantics of slice objects themselves, slice notation
isn't limited to a single slice object; it can also return a tuple of
slices and values, e.g.:

> numpy.s_[1::2,...,3,4:5:6]
(slice(1, None, 2), Ellipsis, 3, slice(4, 5, 6))

For a single slice, enumerating over a slice with an unspecified stop
value would be equivalent to itertools.count(). Negative stop values won't
work.

For a multi-dimensional slice, with everything specified, you would
probably want to iterate over the cartesian product (i.e. N nested loops
for an N-dimensional slice). But this won't work if anything other than
the outermost loop has an unspecified stop value, or if you use an
ellipsis within a slice.

Oh, and being able to slice a slice could be quite useful, i.e.:

[10:90:10][2::2] == [30:90:20]

cf:
> numpy.arange(100)[10:90:10][2::2]
array([30, 50, 70])
> numpy.arange(100)[30:90:20]
array([30, 50, 70])

From: Colin W. on
On 17-Dec-09 20:00 PM, Nobody wrote:
> On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:
>
>> Many more people uses range objects (xrange in 2.x). A range object has
>> the same info as a slice object *plus* it is iterable.
>
> This isn't quite true, as a range cannot have a stop value of None, i.e.
> you can't represent [n:] or [:] etc as a range. Similarly for using
> negative stop values for indices relative to the end of the sequence being
> sliced.
>
> Also, aside from the semantics of slice objects themselves, slice notation
> isn't limited to a single slice object; it can also return a tuple of
> slices and values, e.g.:
>
> > numpy.s_[1::2,...,3,4:5:6]
> (slice(1, None, 2), Ellipsis, 3, slice(4, 5, 6))
>
> For a single slice, enumerating over a slice with an unspecified stop
> value would be equivalent to itertools.count(). Negative stop values won't
> work.
>
> For a multi-dimensional slice, with everything specified, you would
> probably want to iterate over the cartesian product (i.e. N nested loops
> for an N-dimensional slice). But this won't work if anything other than
> the outermost loop has an unspecified stop value, or if you use an
> ellipsis within a slice.
>
> Oh, and being able to slice a slice could be quite useful, i.e.:
>
> [10:90:10][2::2] == [30:90:20]
>
> cf:
> > numpy.arange(100)[10:90:10][2::2]
> array([30, 50, 70])
> > numpy.arange(100)[30:90:20]
> array([30, 50, 70])
>
You don't say, but seem to imply that the slice components include None.

Section 5.3.3 of the Python doc for 2.6.4 has

The lower and upper bound expressions, if present, must evaluate to
plain integers; defaults are zero and the sys.maxint, respectively. If
either bound is negative, the sequence's length is added to it. The
slicing now selects all items with index k such that i <= k < j where i
and j are the specified lower and upper bounds. This may be an empty
sequence. It is not an error if i or j lie outside the range of valid
indexes (such items don't exist so they aren't selected).

Colin W.
From: Colin W. on
On 17-Dec-09 20:00 PM, Nobody wrote:
> On Mon, 14 Dec 2009 14:18:49 -0500, Terry Reedy wrote:
>
>> Many more people uses range objects (xrange in 2.x). A range object has
>> the same info as a slice object *plus* it is iterable.
>
> This isn't quite true, as a range cannot have a stop value of None, i.e.
> you can't represent [n:] or [:] etc as a range. Similarly for using
> negative stop values for indices relative to the end of the sequence being
> sliced.
>
> Also, aside from the semantics of slice objects themselves, slice notation
> isn't limited to a single slice object; it can also return a tuple of
> slices and values, e.g.:
>
> > numpy.s_[1::2,...,3,4:5:6]
> (slice(1, None, 2), Ellipsis, 3, slice(4, 5, 6))
>
> For a single slice, enumerating over a slice with an unspecified stop
> value would be equivalent to itertools.count(). Negative stop values won't
> work.
>
> For a multi-dimensional slice, with everything specified, you would
> probably want to iterate over the cartesian product (i.e. N nested loops
> for an N-dimensional slice). But this won't work if anything other than
> the outermost loop has an unspecified stop value, or if you use an
> ellipsis within a slice.
>
> Oh, and being able to slice a slice could be quite useful, i.e.:
>
> [10:90:10][2::2] == [30:90:20]
>
> cf:
> > numpy.arange(100)[10:90:10][2::2]
> array([30, 50, 70])
> > numpy.arange(100)[30:90:20]
> array([30, 50, 70])
>
You don't say, but seem to imply that the slice components include None.

Section 5.3.3 of the Python doc for 2.6.4 has

The lower and upper bound expressions, if present, must evaluate to
plain integers; defaults are zero and the sys.maxint, respectively. If
either bound is negative, the sequence's length is added to it. The
slicing now selects all items with index k such that i <= k < j where i
and j are the specified lower and upper bounds. This may be an empty
sequence. It is not an error if i or j lie outside the range of valid
indexes (such items don't exist so they aren't selected).

Colin W.
From: Nobody on
On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote:

> You don't say, but seem to imply that the slice components include None.

That's how missing components are implemented at the language level:

> class foo:
= def __getitem__(self, s):
= return s
=
> x = foo()
> x[::]
slice(None, None, None)
> x[1::2]
slice(1, None, 2)

The defaults of zero, sys.maxint and one apply to built-in types, but
nothing forces user-defined types to behave this way.

Or maybe I misunderstood your point.