On 5/1/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > If you want to get my general opinion; -1 on all of your recommendations. > In each part, I describe why. > > Alexander Belopolsky <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
