[Python-Dev] PEP Proposal: Revised slice objects & lists use slice objects as indexes

[Forrest Voight]

This would simplify the handling of list slices.

Slice objects that are produced in a list index area would be different,
and optionally the syntax for slices in list indexes would be expanded
to work everywhere. Instead of being containers for the start, end,
and step numbers, they would be generators, similar to xranges.

Lists would accept these slice objects as indexes, and would also
accept any other list or generator.

Last, slice objects would be able to be added for multiple index
ranges of a list. The new slice object would keep a list of ranges.

Optionally, the 1:2 syntax would create a slice object outside of list
index areas. It would be shorthand for slice, as [] is for list. This
would create some confusion in loops and conditionals due to the colon
being used for the end of the structure. (see last example)

This would be incompatible with classes that define __setitem__ and
__getitem__, and would need changes in how slices are handled in
CPython. Therefore, this is probably a proposal for Python 3000.

Examples:

>>> 1:5
1:5

>>> list(1:5)
[1, 2, 3, 4]

>>> list(1:5:2)
[1, 3]

>>> s = 1:3
>>> range(5)[s]
[1, 2]

>>> 1:5 + 15:17
1:5 + 15:17

>>> range(30)[1:5 + 15:17]
[1, 2, 3, 4, 15, 16]

>>> range(100)[[1,2,3]]
[1, 2, 3]

>>> range(100)[1,2,5] # maybe
[1, 2, 5]

>>> for x in :15:3: print x # maybe
0
3
6
9
12

---
Forrest Voight
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP Proposal: Revised slice objects & lists use slice objects as indexes

[Forrest Voight]

>  I am not sure what you are trying to propose here. The slice object
>  isn't special, it's just a regular built-in type.

 The idea is to have slice objects be generators. You could make a
 slice like 1:10:2 , and that would make a slice object which could be
 used as a list index. The list would return a list with the
 corresponding item for every index in the generator. Then, lists could
 transparently be used as list indexes, or you could supply your own
 generator instead of a slice object.


 >  I don't see how introducing new syntax would simplify indexing.

 It would move the slice logic from the list to the slice object. Now
 the slice object is just a container, but with this it would be
 useful.

 >  Why should lists accept a list or a generator as an index? What is the

>  use case you have in mind?

 For example, a multiple selection box's selection would be changed
 into its values by supplying the chosen indexes into a list of values.


 >  >  Optionally, the 1:2 syntax would create a slice object outside of list
 >  >  index areas.
 >
 >  Again, I don't see how this could be useful...
 >  >
 >  >  >>> list(1:5)
 >  >  [1, 2, 3, 4]
 >  >
 >  >  >>> list(1:5:2)
 >  >  [1, 3]
 >  >
 >
 >  list(range(1,5,2))?

 It would only be useful as shorthand for xrange, but its addition
 capabilities would be useful.


 >  >  >>> range(30)[1:5 + 15:17]
 >  >  [1, 2, 3, 4, 15, 16]
 >  >
 >
 >  This is confusing, IMHO, and doesn't provide any advantage over:
 >
 >   >>> s = list(range(30))
 >   >>> s[1:5] + s[15:17]
 >

 I don't think it's confusing. Also, an advantage would be if the slice
 object were being automatically generated, this would simplify the
 code.



 >  If you really needed it, you could define a custom class with a fancy
 >  __getitem__
 >
 >   class A:
 > def __getitem__(self, x):
 >return x
 >
 >   >>> A()[1:3,2:5]
 >   (slice(1, 3, None), slice(2, 5, None))
 >
 >  P.S. You should consider using the python-ideas
 >  (http://mail.python.org/mailman/listinfo/python-ideas) mailing list,
 >  instead of python-dev for posting suggestions.
 >
 >  Cheers,
 >  -- Alexandre
 >
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com