By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,050 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,050 IT Pros & Developers. It's quick & easy.

Odd slicing behavior?

P: n/a
Take a look at this snippet:
class L(list): .... 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
Jul 19 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Dave Opstad wrote:
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
Jul 19 '05 #2

P: n/a
In article <3h************@uni-berlin.de>,
"Diez B. Roggisch" <de***@web.de> wrote:
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
Jul 19 '05 #3

P: n/a
Dave Opstad wrote:
In article <3h************@uni-berlin.de>,
"Diez B. Roggisch" <de***@web.de> wrote:

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.


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
Jul 19 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.