Odd slicing behavior?

[Dave Opstad]

Take a look at this snippet:
.... def __init__(self, v):
.... super(L, self).__init__(v)
.... def __setitem__(self, key, value):
.... print key.indices(len(self))
....

v = L(range(10))
v [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
v[::] = [1] (0, 10, 1)
v[0:10:1] = [1]

(0, 10, 1)

So both assignments result in slices with exactly the same start, stop
and step values: 0, 10 and 1. Also, the __setitem__ method is being
called, not the older __setslice__ method; we can tell this because it
hit the print statement.

However, actually trying to make a slice assignment on a regular list in
these two ways behaves differently:

v2 = range(10)
v2[0:10:1] = [1]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: attempt to assign sequence of size 1 to extended slice of
size 10

v2[::] = [1]
v2

[1]

So given the equality of their slice representations, why do the v2[::]
and v2[0:10:1] assignments behave differently? My reading of section
5.3.3 of the manual suggests that these should behave the same.

If I'm just not seeing something obvious, please let me know!

Thanks,
Dave

 

[Diez B. Roggisch]

So given the equality of their slice representations, why do the v2[::]
and v2[0:10:1] assignments behave differently? My reading of section
5.3.3 of the manual suggests that these should behave the same.

If I'm just not seeing something obvious, please let me know!

It's not so much obvious - I had to experiment myself a little bit. This
works:

v[0:10] = [1]

So what can we conclude from that? It seems that what is implied by the
slice-assignment syntax is that the slice is contingous. The reason
becomes obvious when one does something like this:

v[0:10:2] = [1,2]

What do you expect to happen in this case?

So - the rationale seems to be: "When using slice-assignment, a form
like l[a:b:c] imposes possibly a non-continous section in l, for which
the semantics are unclear - so we forbid it"

It should be mentioned in the docs, though - and on could argue if
[a:b:c] == [a:b] could be checked for at runtime (c being 1). But then -
if you really wanted that, you could have written [a:b] in the first place.

So - I'd say it's an doc-error at most

Diez

 

[Dave Opstad]

So - the rationale seems to be: "When using slice-assignment, a form
like l[a:b:c] imposes possibly a non-continous section in l, for which
the semantics are unclear - so we forbid it"

But it isn't forbidden:

v = range(10)
v [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
v[0:10:3] = ['a', 'b', 'c', 'd']
v

['a', 1, 2, 'b', 4, 5, 'c', 7, 8, 'd']

The only time it's actively forbidden is when the length of the slice
and the length of the list being assigned to it don't match.

I agree with you that it might be nice for [a:b:1] and [a:b] to be
treated synonymously.

Dave

 

[Diez B. Roggisch]

So - the rationale seems to be: "When using slice-assignment, a form
like l[a:b:c] imposes possibly a non-continous section in l, for which
the semantics are unclear - so we forbid it"

But it isn't forbidden:


[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

v[0:10:3] = ['a', 'b', 'c', 'd']
v

['a', 1, 2, 'b', 4, 5, 'c', 7, 8, 'd']

The only time it's actively forbidden is when the length of the slice
and the length of the list being assigned to it don't match.

Oh, cool. But then the semantics are clear: if using [a:b:c] syntax, the
replaced slice has to be of same lenght. Makes sense - and in that
case, I'd prefer c==1 not to be special cased - for the sake of a more
clearly defined behaviour.

Regards,

Diez