On Sat, Feb 24, 2018 at 5:24 AM, Chris Barker
On Thu, Feb 22, 2018 at 6:21 PM, Nick Coghlan
wrote: (I wonder if the discrepancy is due to some internal interface that loses the distinction between None and 1 before the decision is made whether to use advanced slicing or not. But that's a possible explanation, not an excuse.)
That explanation seems pretty likely to me, as for the data types implemented in C, we tend to switch to the Py_ssize_t form of slices pretty early, and that can't represent the None/1 distinction.
Even for Python level collections, you lose the distinction as soon as you call slice.indices (as that promises to return 3-tuple of integers).
If this is the case -- backward compatibility issues aside, wouldn't it be very hard to fix?
Which means that should be investigated before going to far down the "how much code might this break" route.
And certainly before adding a Deprecation Warning.
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. ChrisA