[Python-ideas] List assignment - extended slicing inconsistency

[Chris Angelico]

On Sat, Feb 24, 2018 at 6:38 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 23.02.18 20:50, Chris Angelico пише:
>>
>> Ignoring backward compatibility, it ought to be possible to (ab)use a
>> stride of zero for this. Calling slice.indices() on something with a
>> stride of zero raises ValueError, so there's no ambiguity. But it
>> would break code that iterates in a simple and obvious way, and (ugh
>> ugh) break it in a very nasty way: an infinite loop. I'm not happy
>> with that kind of breakage, even with multiple versions posting a
>> warning.
>>
>> In the C API, there's PySlice_GetIndices "[y]ou probably do not want
>> to use this function" and PySlice_GetIndicesEx, the "[u]sable
>> replacement". Much as I dislike adding *yet another* function to do
>> basically the same job, I think that might be the less-bad way to do
>> this.
>
>
> Actually PySlice_GetIndicesEx is deprecated too. It is not safe for
> resizeable sequences since it is vulnerable to race condition. The pair of
> PySlice_Unpack() and PySlice_AdjustIndices() replaces it in new code.
>
> So now we have 4 functions for doing the same thing in C, 2 of them are
> deprecated. Do you want to deprecate the other two and add new replacements
> for them?
>

Wow. Who'd have thought slice indexing was so hard...

(If you look at the Python 3.6 docos, that deprecation isn't
mentioned. Should it be?)

I presume it's already too late for 3.7 to change anything to fix this.

ChrisA