Assigning to a slice of a list with a step of -1 should permit assigning a different number of items

[larryhastings]

Feature or enhancement

Proposal:

(Note: this behavior is so old, I'd be surprised if genuinely nobody had ever suggested it before. So I give it a 30% chance it's actually a bad idea for some reason I've missed. Nevertheless--let's give it a go.)

In Python, you can assign to a slice of a list. The right hand side must be an iterable, and the values it yields replace the corresponding elements of the list:

>>> l = [1, 2, 3, 4, 5]
>>> l[1:4] = 'abc'
>>> l
[1, 'a', 'b', 'c', 5]

For a non-extended slice, where step is either None or 1, the number of items yielded by the iterable and the length of the slice don't need to agree. The list object will happily replace the sliced elements with all the elements of the iterable:

>>> l = [1, 2, 3, 4, 5]
>>> l[1:4] = 'abcdef'
>>> l
[1, 'a', 'b', 'c', 'd', 'e', 'f', 5]

You can also assign to an extended slice, defined as any slice with a step != 1:

>>> l = [1, 2, 3, 4, 5]
>>> l[0:5:2] = 'abc'
>>> l
['a', 2, 'b', 4, 'c']

But when step is != 1, the number of elements yielded by the iterable and the length of the slice must agree:

>>> l = [1, 2, 3, 4, 5]
>>> l[0:5:2] = 'abcdef'
ValueError: attempt to assign sequence of size 6 to extended slice of size 3

If you assign to a slice with a negative step, it actually assigns the values in reverse:

>>> l = [1, 2, 3, 4, 5]
>>> l[3:0:-1] = 'abc'
>>> l
[1, 'c', 'b', 'a', 5]

But a step of -1 means this is an "extended" slice, so the list object requires the size of the iterable and the length of the slice to agree:

>>> l = [1, 2, 3, 4, 5]
>>> l[3:0:-1] = 'abcdef'
ValueError: attempt to assign sequence of size 6 to extended slice of size 3

I think this is a flaw. I claim that

>>> l = [1, 2, 3, 4, 5]
>>> l[1:4] = 'abcdef'

and

>>> l = [1, 2, 3, 4, 5]
>>> l[3:0:-1] = reversed('abcdef')

should produce identical results; they should both set l to [1, 'a', 'b', 'c', 'd', 'e', 'f', 5].

In summary: Python should permit assigning an iterable to a slice where the iterable and slice are of different magnitudes if step is 1 or -1.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[StanFromIreland]

I have hidden the above comment as VirusTotal reports that the folder (fix.zip) is malware. See report.

[Eclips4]

I have hidden the above comment as VirusTotal reports that the folder (fix.zip) is malware. See report.

I've deleted & reported to GitHub that comment.

[larryhastings]

I suppose I can state it more generally. I propose that, for any list L, any iterable iterable, and any legal int values of start and stop,

>>> L[start:stop] = iterable

and

>>> L[stop-1:start-1:-1] = reversed(iterable)

should produce identical results.

[pochmann3]

@larryhastings Those list slices can differ very much:

L = [1, 2, 3]
start, stop = 0, 3
print(L[start:stop])
print(L[stop-1:start-1:-1])

Output:

[1, 2, 3]
[]

[larryhastings]

@larryhastings Those list slices can differ very much:

L = [1, 2, 3]
start, stop = 0, 3
print(L[start:stop])
print(L[stop-1:start-1:-1])

Output:

[1, 2, 3]
[]

Good point. Also, slicing into lists clamps, so crazy out-of-range numbers could have wacky effects.

Let's restrict the range of start and stop to 1..len(L). If start is 0 in the step=1 (forwards) version, you could leave start blank for the step=-1 (reversed) version, I think that works too.

[serhiy-storchaka]

This will significantly complicate the implementation. Note, that we would need to support this not only in list, but in bytearray, array, MutableSequence, whatever.

Is it really so important that assigning reversed(...) or list(...)[::-1] is not enough? The implementation in C will be equivalent to assigning list(...)[::-1] or reversed(list(...)) -- first create a temporary list from the input, then reserve space in the target list, then copy from the temporary list in the reversed order.

[larryhastings]

Is it really so important that assigning reversed(...) or list(...)[::-1] is not enough? The implementation in C will be equivalent to assigning list(...)[::-1] or reversed(list(...)) -- first create a temporary list from the input, then reserve space in the target list, then copy from the temporary list in the reversed order.

Given that the slice object is now 29 years old, and Python has never supported this behavior, no obviously it's not important. Otherwise we would have fixed this decades ago.

Speaking personally, I rarely assign to a slice, and I don't think I've ever assigned to a slice with a negative step. So I don't actually care that much whether or not this gets fixed. I didn't file this issue because I want to use the functionality--and if we add the functionality I doubt I ever would use it.

But I argue Python is being inconsistent here:

• Python allows replacing a slice using a positive step with an iterable; the values from the iterable are assigned in forwards order.
• Python allows replacing a slice using step 1 with an iterable yielding a different number of items; the values from the iterable are assigned in forwards order.
• Python allows replacing a slice using a negative step with an iterable; the values from the iterable are assigned in reverse order.

Therefore I assert Python should allow replacing a slice using step -1 with an iterable yielding a different number of items, in which case the values from the iterable would be assigned in reverse order.

I'm only filing this issue because Python is being inconsistent, and I prefer that Python be consistent. So this issue is only important to the extent that you think Python being consistent is important. If you're fine with Python being inconsistent, then the practicality-beats-purity perspective suggests we shouldn't bother to fix this.

[serhiy-storchaka]

There are two concepts merged together.

List and other standard sequences support simple slicing. They support replacing a slice with an iterable yielding a different number of items.

>>> a = list(range(10))
>>> a[:] = range(20)
>>> a[:] = range(5)

NumPy arrays support extended slicing. But they do not support replacing a slice with an iterable yielding a different number of items. Even a slice with step 1.

>>> import numpy as np
>>> a = np.arange(10)
>>> a[:] = range(10, 20)
>>> a[:] = range(20)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not broadcast input array from shape (20,) into shape (10,)
>>> a[:] = range(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not broadcast input array from shape (5,) into shape (10,)

Standard sequences also have limited support for extended slicing (only single slice object, no ellipsis). No type fully supports them. Anyway, the ability of replacing a slice with an iterable yielding a different number of items came from simple slicing, not extended slicing. It remains for compatibility and because it is generally useful. But there was no reason to support this for extended slicing with step -1 when even NumPy arrays do not support this.

[larryhastings]

I admit I'm not very interested in what NumPy does and doesn't do. NumPy doesn't define Python behavior.