[Python-3000] Future of slices

[Alexander Belopolsky]

On 5/1/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> If you want to get my general opinion; -1 on all of your recommendations.
> In each part, I describe why.
>
> Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> > 1. l[:] syntax for shallow copy.
>
> Note that [:] doesn't necessarily copy.

I know. It does not in numpy. However, I understand that the ability
to do l[:] when l is
a list justified not having list.copy method.  The fact that l[:] is
not  necessarily a copy
makes it even less attractive way to express copy(l).

>  It certainly is the case for
> Python lists, strings, tuples, and unicode today, but given standard
> slicing of l[i:j] producing a copy of a section of a list/string/tuple
> from i...j, removing the first is equivalent to 'the start', and
> removing the second being equivalent to 'the end'; having l[:] do
> something other than slicing the entire sequence (at least for
> list/string/tuple) seems pretty unintuitive.
>

I did not propose l[:] doing anything different.  I was actually very
shy proposing anything, but if I must, the proposal  would be:

1. Replace l[start:stop:step] with l.slice(start, stop, by=step)
2. Replace l[start:stop:step] = x with l.setslice(x, start, stop, by=step)


> >
> > 2. Overloading of [] syntax. The primary meaning of c[i] is: get the
> > i-th item from the collection.
> [snip]
> > The main problem with [] overloading is that c[i] is not
> > guaranteed to be "smaller" than c.
>
> How is this related at all to anything?
>

This has to do with an expectation that c[i][j]... should eventually
throw an exception unless
you managed to create a circular list.  I put "smaller" in quote marks
because [0,1] being smaller than  [[0,1]] is subjective (one might say
it's the other way around because len([0,1]) > len([[0,1]])). What I
wanted to say is that the traditional meaning of subscripting
is to obtain an item from a container and not a container with
possibly fewer items.


> > This problem is even worse for strings, where c[i] is
> > *always* a slice: c[i] is the same as c[i:i+1].
>
> No.
>     >>> ''[0]
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     IndexError: string index out of range
>     >>> ''[0:1]
>     ''
>
I did not realize that.  I would not call this behavior obvious.
Particularly given

>>> ''[10:11]
''


> > maybe we can reconsider compiling l[a:b:c] into
> > l.__getitem__(slice(a,b,c)) and go back to __getslice__.
>
> You can still use __getslice__ if you want (I believe it is deprecated,
> but I don't know when it will be removed)...

I assumed that deprecated features will be gone in Py3K.


[snip]

> Which would you rather do:
>     b = a[i:j]
> or
>     b = str(a[k] for i in xrange(i,j))
>
> Obviously the first.  People who use extended slicing feel the same way,
> as they can add a :X and have precisely what they want.

I would rather do substr(a, i, j).  In the presence of variable
character width encodings
(think UTF-8) substr may even need an encoding argument to operate
properly unless
encoding becomes a property of the string.  As far as strings go, I
would rather see them
non-iterable, non-subscriptable with a large library of methods and
functions.  I understand
that someone else have already lost this battle for me though.

-- sasha