[Python-3000] Future of slices

[Josiah Carlson]

"Alexander Belopolsky" <alexander.belopolsky at gmail.com> wrote:
> 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.

That seems a bit silly to me, but I would use list(l) to make a copy
rather than l.copy() in any case.  Or even type(l)(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)

I don't like the ordering on the setslice method, and I'm -1 on the idea
of replacing slicing with methods.


> > > 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

I disagree.  The only expectation I have about c[i] is that I will be
getting some item, referenced by i, from c.  In the case of strings, I
can say c[0][0][0][0][0][0][0][0]..., so as long as c is not an empty
string.

In the case of graphs implemented as dictionaries, I can choose a random
walk from the items and never stop (assuming bidirectional links).


> 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]
> ''

In my experience and expectation, slicing generally doesn't fail on
standard objects...

    >>> ()[1:2]
    ()
    >>> [][1:2]
    []
    >>>

...even when you do something seemingly foolish...

    >>> ''[1:0]
    ''

I think this is a positive feature of slicing, at least with the
standard Python types.


> > 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.

In Py3k, all strings are unicode, so discussion about encodings during
string slicing is unrelated to the topic at hand.

If you want substr(a, i, j) to be your slicing operator, you can define
such things in your site.py, and wrap whatever makes it into Python 2.x
or 3.x .

 - Josiah