[Python-3000] Future of slices

[Alexander Belopolsky]

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.