Someone then pointed out that the proposal is equally fine because, despite what Bruce suggested, you can get the A result with two slices.
But if you take away the ability to specify A in a single slice, you take away the ability to assign to A.
Imagine I'd written s[:-5:-2]=1, 3 (or equivalently s[:5:-2]) and the language changed to make this now replace the 8 and 6 instead of the 9 and 7. How would I change my code to get the previous behavior back?
It's quite possible no one has ever intentionally written such code. Or, even if they _have_, that they shouldn't have. (You can hardly call something readable if you have to sit down and work through what it would do to various sequences.) And correctly supporting such nonexistent code has been a burden on every custom sequence ever implemented.
So, a proposal that makes strides < -1 with non-None end points into an error (as some of them have) seems reasonable.
But I think a proposal that changes the meaning of such slices into something different (as some of them have) is a lot riskier. (Especially since many custom sequences that didn't implement slice assignment in the clever way would have to be rewritten.)
But that doesn't work with assignment; you're just assigning to the temporary copy
of the first slice.
...
Do you have a specific example of a currently-working slice assignmentthat couldn't easily be done under proposed alternatives?
s[:-4:-2]=1, 2
This replaces the last and antepenultimate elements, whether s is even or odd.
I suppose you could mechanically convert it to this:
s[-mid+2::2]=reversed((1,2))
But I don't know that I'd call that "easy".
The question is whether this is realistic code anyone would ever intentionally write.