[Python-3000] Future of slices
alexander.belopolsky at gmail.com
Mon May 1 21:14:22 CEST 2006
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.
> > 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].
> >>> ''
> 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.
> > 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.
> Which would you rather do:
> b = a[i:j]
> 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
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.
More information about the Python-3000