RetroSearch Browse

Mon Mar 10 01:35:09 CET 2008 · http://mail.python.org/pipermail/python-dev/2008-March/077519.html

On Sun, Mar 9, 2008 at 7:21 PM, Forrest Voight <voights at gmail.com> wrote:
> 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.

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.

  >>> slice(1,4)
  slice(1, 4, None)
  >>> [1,2,3,4,5,6][slice(1,4)]
  [2, 3, 4]

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

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

Why lists should accept a list or a generator as index? What is the
use case you have in mind?

>  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))?

>  >>> 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]

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2008-March/077519.html below:

Revised slice objects & lists use slice objects as indexes