On Sat, Feb 24, 2018 at 6:38 AM, Serhiy Storchaka <storch...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
