Consider the following:
>>> x = [0, 1, 2, 3, 4]
>>> x[-1:0] = [5, 6, 7]

Currently the result is that x == [0,1,2,3,5,6,7,4]. 
However, I believe that calling setitem with an empty
slice should be a no-op, rather than performing an
insertion starting at the 'begin' index of the slice.

The following patch to Objects/listobject.c makes this
change.

Thanks,
Jonathan Brandmeyer

Logged In: YES 
user_id=80475

I believe we are stuck with this one.  Assigning to an empty
slice like a[2:2]=list('hotdog') is a valid and useful.  The
weird part is that the rightmost index gets adjusted to make
the most sense given the leftmost index.  In your example,
the offerred indices of -1 and 0 would seem to indicate a
programming error.  However, this autoadjusting is a long
standing feature and occassionally useful in its own right.

Logged In: YES 
user_id=676765

Consider this alternate example which should mean exactly
the same thing, but doesn't:
>>> x = [0, 1, 2, 3, 4]
>>> x[-1:0:1] = [5, 6, 7]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: attempt to assign sequence of size 3 to extended
slice of size 0

Logged In: YES 
user_id=676765

Here is a snippet from a conversation that occured on the
python-c++ list in January:

> So now the question is,
> what is the result of replacing an empty slice in a
container with a
> non-empty sequence? If the container supports insertion,
inserting the
> sequence seems logical enough to me.

So how do you define the point to perform the insertion?  If
the user asks to replace every element that is greater than
or equal to the fourth and less than the first element,
where do you place the new sequence?

The current action for a built-in list is to range-limit the
stop point to be not less than the start point, but I think
that is just for safety rather than an API decision, and
that it is wrong.

Logged In: YES 
user_id=80475

IMO, the risks of changing this outweight any possible
benefits.  I would be interested to see whether others would
rally for or against 
this one.

Logged In: YES 
user_id=593130

Empty slice 'replacement' as insertion is an intentional 
feature.  It actually defines indexed insertion:  Lib REf 2.3.6.4 
Mutable Sequence Types says 
"s.insert(i, x) same as s[i:i] = [x] (5) "

 .insert was recently changed to make this exactly true:
 "(5) When a negative index is passed as the first parameter 
to the insert() method, the list length is added, as for slice 
indices. If it is still negative, it is truncated to zero, as for 
slice indices. Changed in version 2.3: Previously, all negative 
indices were truncated to zero."

It is also a feature (intentional, I presume) of slices that they 
always work (unlike indices).  The current behavior is what I 
expect.

To be clearer,
  "s[i:j] = t   slice of s from i to j is replaced by t "
in the table should grow a footnote:
  "If j < i, j becomes i." (or "is replaced by")
This is my suggested resolution of this item (but I am not a 
Latexer).

As for extended slice assignment, "should mean exactly the 
same thing" is simply wrong as a general statement.  The 
manual says
"s[i:j:k]=t the elements of s[i:j:k] are replaced by those of t 
(1)" and the footnote says
"(1) t must have the same length as the slice it is replacing" 
which is quite different simple slice replacement.  The error 
message has nothing to do with the 0 length of the target 
other than that it is different from the source.  s[0:1:1] = 
[5,6] is also invalid even though s[0:1] = [5,6] works (given 
len(s) >= 1).

Logged In: YES 
user_id=676765

Very well.  Thanks for the clarification.