GeezerVison

The C Element.__setitem__ shifted the children from stop but wrote the new ones from start, so e[5:2] = [x] duplicated one child without taking a reference and overwrote another. This normalizes stop to start the same way list does (adjust_slice_indexes in Objects/listobject.c), which is what the Python implementation already gets from its list.

The new test compares a few backward slices with the same assignment on a list, so it covers both implementations. On main the C one crashes: the example from the issue segfaults on a debug build, and with ASan, dropping the parent gives a heap-use-after-free in element_dealloc. With the fix, both builds keep all the children, test_xml_etree and test_xml_etree_c pass, and -R 3:3 on the slice tests shows no leaks.

• Issue: ElementTree slice assignment with start greater than stop duplicates a child without owning its second reference #161689