On 23 February 2018 at 11:51, Guido van Rossum <gu...@python.org> wrote:
> On Thu, Feb 22, 2018 at 2:18 PM, Alexander Heger <pyt...@2sn.net> wrote:
>> But I disagree that there should be no error when it is wrong.
>> *Strides that are not None should always trigger advanced slicing.*
> This makes sense.
> (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

>> Concerns
>> ========
>> It may break some code that uses advanced slicing and expects regular
>> slicing to occur?  These cases should be rare, and the error message should
>> be clear enough to allow fixes? I assume these cases should be exceptionally
>> rare.
> Yeah, backwards compatibility sometimes prevents fixing a design bug. I
> don't know if that's the case here, we'll need reports from real-world code.

In this case, we should be able to start with a DeprecationWarning in
3.8, since we already have the checks in place to raise ValueError
when the step is 2 or more - any patch would just need to make sure
those checks either have access to the original slice object (so they
can check the raw step value), or else an internal flag indicating
whether or not an explicit step was provided.

So the next step would be to file an issue pointing back to this
thread for acknowledgement that this is a design bug to be handled
with a DeprecationWarning in 3.8, and a ValueError in 3.9+.


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to