From: Dave on
Just as sets may now be written as {3,'hi'}, I propose that slices
should be available using [start:end] syntax. Following example comes
from projecteuler.net problem 166. The Numeric community would also
like this, as would the general python user. The slice notation would
require one ":" between the brackets to differentiate it from a list,
which is similar to the set notation requirement that disambiguates it
from a dictionary.

Several times now I've wanted python slice notation. Perhaps I'll
write a Python Enhancement Proposal. I stored slices of vector array
entries to add


edge = 4
indexes = []
n = edge
nn = n**2
for i in range(edge):
indexes.extend([
slice(i*n,(i+1)*n,1), # rows
slice(i,nn,n), # cols
])

row_slices = indexes[0::2]
col_slices = indexes[1::2]
slash = slice(n-1,n*(n-1)+1,n-1)
backslash = slice(0,nn,n+1)


Which could have been written in a manner completely consistent with
other python shorthand notations and for which python "cannot
possibly" use the notation for some other purpose,


edge = 4
indexes = []
n = edge
nn = n**2
for i in range(edge):
indexes.extend([
[i*n: (i+1)*n] # rows
[i: nn: n], # cols
])

row_slices = indexes[0::2]
col_slices = indexes[1::2]
slash = [n-1: n*(n-1)+1: n-1]
backslash = [0: nn: n+1]
From: geremy condra on
http://www.python.org/dev/peps/pep-3003/

Geremy Condra
From: Colin W. on
On 14-Dec-09 13:03 PM, Dave wrote:
> Just as sets may now be written as {3,'hi'}, I propose that slices
> should be available using [start:end] syntax. Following example comes
> from projecteuler.net problem 166. The Numeric community would also
> like this, as would the general python user. The slice notation would
> require one ":" between the brackets to differentiate it from a list,
> which is similar to the set notation requirement that disambiguates it
> from a dictionary.
>
> Several times now I've wanted python slice notation. Perhaps I'll
> write a Python Enhancement Proposal. I stored slices of vector array
> entries to add
>
>
> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
> indexes.extend([
> slice(i*n,(i+1)*n,1), # rows
> slice(i,nn,n), # cols
> ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = slice(n-1,n*(n-1)+1,n-1)
> backslash = slice(0,nn,n+1)
>
>
> Which could have been written in a manner completely consistent with
> other python shorthand notations and for which python "cannot
> possibly" use the notation for some other purpose,
>
>
> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
> indexes.extend([
> [i*n: (i+1)*n] # rows
> [i: nn: n], # cols
> ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = [n-1: n*(n-1)+1: n-1]
> backslash = [0: nn: n+1]

Yes, we know that PEP 3003 applies but I see no harm in discussing
possible enhancements.

The existing slice seems a little different from what you are proposing:
An object usually containing a portion of a sequence. A slice is created
using the subscript notation, [] with colons between numbers when
several are given, such as in variable_name[1:3:5].
or:
Slice objects
Slice objects are used to represent slices when extended slice syntax is
used. This is a slice using two colons, or multiple slices or ellipses
separated by commas, e.g., a[i:j:step], a[i:j, k:l], or a[..., i:j].
They are also created by the built-in slice() function.

If your scheme flies, would it be practicable to use the same syntax
as a range generator?

range(i, j, k) => i:j:k

so range(10, 2) => :10:2

i.e. we could write for i in :10:2:

or the more common:
range(10) => :10

Colin W.


From: geremy condra on
> Yes, we know that PEP 3003 applies but I see no harm in discussing possible
> enhancements.

I don't think the OP knew that the moratorium was in effect. That's why I
brought it up.

Geremy Condra
From: Terry Reedy on
On 12/14/2009 1:03 PM, Dave wrote:
> Just as sets may now be written as {3,'hi'}, I propose that slices
> should be available using [start:end] syntax.

I believe this has been proposed and rejected on one of the py-dev,
py-ideas, or py-3k lists, but I would have to check to be sure.

Extended slices would also have to be allowed.

> The Numeric community would also like this,

Evidence? Are you one of the leaders thereof?

> as would the general python user.

A few might but most would find it useless since they never write
explicit slice objects and would have to learning something new to read
code like the below.

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. 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.
However, his has also, I believe, been rejected, as an abbreviation too far.

> Several times now I've wanted python slice notation. Perhaps I'll
> write a Python Enhancement Proposal.

That could be useful, even if it gets rejected. Or perhaps this should
be added to 3099.

> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
> indexes.extend([
> slice(i*n,(i+1)*n,1), # rows
> slice(i,nn,n), # cols
> ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = slice(n-1,n*(n-1)+1,n-1)
> backslash = slice(0,nn,n+1)
>
> Which could have been written in a manner completely consistent with
> other python shorthand notations

Python avoids getting to chicken-scratchy. There was even a proposal
(rejected, see 3099) to deprecate [1,2,3], etc, in favor of list(1,2,3),
etc.

> and for which python "cannot possibly" use the notation for some
other purpose,

But it could, see above.

> edge = 4
> indexes = []
> n = edge
> nn = n**2
> for i in range(edge):
> indexes.extend([
> [i*n: (i+1)*n] # rows
> [i: nn: n], # cols
> ])
>
> row_slices = indexes[0::2]
> col_slices = indexes[1::2]
> slash = [n-1: n*(n-1)+1: n-1]
> backslash = [0: nn: n+1]

I find this currently to be less readable.

Terry Jan Reedy