[Python-3000] Future of slices
Alexander Belopolsky
alexander.belopolsky at gmail.com
Mon May 1 04:50:28 CEST 2006
Since Py3K is going to considerably change the behavior of the
fundamental collection types, it may be appropriate to revisit the
design of slicing. I would like to start the discussion by
mentioning some of the python 2.x slicing features that I don't
like. I fully anticipate that most of the following will quickly
end up in PEP-3099, but that by itself is progress :-).
1. l[:] syntax for shallow copy. I remember this being discussed
before, but could not dig out that discussion. The difficulty
finding the old discussion on this topic illustrates the point: this
feature is not easily discoverable ("[:]" is a rare Google query that
results in an empty page:-). In 2.x TOOWTDI: from copy import copy;
copy(l), which is a better way for several reasons (explicit choice
wrt. copy/deepcopy, consistency with the other collection types:
dict, set, etc.)
2. Overloading of [] syntax. The primary meaning of c[i] is: get the
i-th item from the collection. This meaning is consistent between
lists/tuples and dicts. The only difference is that i may not be an
integer in the case of dict. Slicing is specific to lists, tuples
and strings (I am ignoring non-built-in types for now). This is an
operation that is very different from "get item", but uses the same
syntax. The main problem with [] overloading is that c[i] is not
guaranteed to be "smaller" than c. If i = slice(None), c[i] is a
copy of i. This problem is even worse for strings, where c[i] is
*always* a slice: c[i] is the same as c[i:i+1]. I think it would be
better to have the slicing functionality provided by named functions
or methods, for example l.slice(start, stop, stride) instead of l
[start:stop:stride]. If that is deemed to result in a different
language, maybe we can reconsider compiling l[a:b:c] into
l.__getitem__(slice(a,b,c)) and go back to __getslice__.
3. Overloading of []= syntax. Similarly to #2, this is the case when
the same notation is used to do conceptually different operations.
In addition it provides alternative ways to do the same thing (e.g. l
+= a vs. l[len(l):] = a).
4. Extended slicing. I believe the most common use case l[::-1] was
eliminated with the introduction of "reversed". The remaining
functionality in case of a tuple c can be expressed as tuple(c[i] for
i in range(start,stop, stride)). The later is more verbose than c
[start:stop:stride], but also more flexible.
More information about the Python-3000
mailing list