Assignment to slice

Rich Krauter rmkrauter at
Wed Jan 21 20:15:46 CET 2004

I hope this gets tacked on to the original thread.
Sorry if it doesn't.

I see your point. However I could be wrong, but I
don't know if what you say is really the case, since
negative indexes are just shorthand for

      actual positive index = i + len(x), 

where i is the negative index, and len(x) >= abs(i).


x = [1,2,3,4,5]
x[-4] is equivalent to x[-4+len(x)], which is x[1]
x[-4:-2] is equivalent to x[(-4+len(x)):(-2+len(x))],
which is x[1:3] 

I contend that my restriction may still hold even in
the case of negative indices, since negative indices
(which are just convenient shorthand), should map to
positive indices.

In that case, 
x = [1,2,3]
x[-10:-9] = [54] should return an exception too since,

x[-10:-9] = x[-10+len(x):-9+len(x)] == x[-7:-6], which
is REALLY out of bounds of x. 

Instead python will just tack stuff on to the front of
the array. Which, I still believe, is totally
inconsistent. But what do I know? I have about 5
minutes of python experience. 

I guess I just don't like that behaviour. At least in
perl if I assign something to a list slice:

@x[2..3] = (4,5);

the list grows,  so that the things I inserted are at
the indices where I think I inserted them.
That is, @x  now contains (0,0,4,5).

So later if I ask for $x[3], or $x[4], I get back what
I put there in the first place.

In python this is not true. The indices will change
because of the append-like behavior:

>> x = []
>> x[2:3] = [4,5]
>> x 

That just doesn't seem right. Either always raise an
out-of-bounds exception or always grow the list.
Python seems to be doing a combination of both, and in
an inconsistent way, at that (or, more accurately, in
a way that does'nt make sense to me). 

Oh well. Maybe my problem is that I'm using perl as my
model of consistency. Plus, it's a minor issue anyway.
I just need to be aware of it, and not try to write
perl code in python. I need to learn to write python
code in python.

Thanks for your input.


> This doesn't answer you fully but Python is at least
> consistent in that 
> slicing - as opposed the indexing of your first case
> *never* raises an 
> IndexError.  It's not unique to assignment.  "print 
> x[1000:9000]" works too.>

> The fact that slices can extend outside the current
> range is useful.  
> Otherwise you couldn't use them to extend sequences.
  > Adding to the end 
> would still be possible with your proposed
restriction >on first index., but 
> what if you wanted to add stuff to the *start* of
the > list.  Currently this 
> works:

> >>> x = [1, 2, 3]
> >>> x[-10:-9] = [54]
> >>> x
> [54, 1, 2, 3]

> In this case to be consistent you must insist that
the second index exist in 
> the array, i.e. insist on:

> >>> x[-4:-3] = [54]

> James
> -- 
> James Henderson, Logical Progression Ltd.

> On Wednesday 21 January 2004 5:01 pm, Rich Krauter >
> I do not understand why python behaves the way it
> in the following code:
> Here, Python doesn't like that I'm assigning
> out-of-range.  OK. That's fine.
> >>> x = []
> >>> x[5] = 3
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> IndexError: list assignment index out of range
> However, the following seems very strange. Assigning
> to a slice, over non-existent array indexes, sets
> and x[1].
> >>> x[2:5] = [3,4]
> >>> x
> [3,4]
> >>> x[1000:9000] = [5]
> >>> x
> [3, 4, 5]
> Why does assigning to a slice of non-existent array
> elements fill in the array, starting with the first
> empty array position? (Acts like [].append() or
> [].extend()?)
> Why not raise an out-of-bounds exception here too?
> Wouldn't that be more consistent with the first
> in which I tried to assign out-of-range, and got an
> exception?
> IMO, at least the first index in the slice should be
> required to exist in the array. If not, raise an
> exception. That way, assigning to the slice fills in
> the array in a predicatable way without having to do
> len() checks first to ensure that you know where in
> the array the slice is actually going to be
> But I'm sure it is the way it is for a good reason.
> Hopefully someone can clue me in.
> Thank you in advance.
> Rich

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

More information about the Python-list mailing list