[Python-ideas] Where did we go wrong with negative stride?

Oscar Benjamin oscar.j.benjamin at gmail.com
Mon Oct 28 15:49:11 CET 2013


On 28 October 2013 13:57, Brett Cannon <brett at python.org> wrote:
>
> On Sun, Oct 27, 2013 at 7:20 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> On Sun, 27 Oct 2013 16:56:34 -0500
>> Tim Peters <tim.peters at gmail.com> wrote:
>> > [Guido]
>> > > I wouldn't take out negative strides completely, but I might consider
>> > > deprecating lower and upper bounds other than None (== missing). So
>> > > a[::-1]
>> > > would still work, and a[None:None:-1] would be a verbose way of
>> > > spelling the
>> > > same,
>> >
>> > Happy idea.
>> >
>> > > but a[-1:-6:-1] would be deprecated.
>> >
>> > Not sure I've _ever_ seen that in real life.
>>
>> If it's never seen in real life, then there's probably no urge to
>> deprecate it and later replace it with a new thing, IMHO.
>
> I think there is to minimize even the chance someone has done something like
> this since it's so wonky. We all know someone has somewhere in code out in
> the world.

Are you saying that any code that depends on the current behaviour is
"wonky" and therefore doesn't properly deserve continued support?

I know I have private (numpy-based) code that depends on this
behaviour. There's nothing wonky about me choosing the limits that I
currently need to in order to get the correct slice.

I think that the numpy mailing lists should be consulted before any
decisions are made. As Antoine says: if you've never noticed this
behaviour before then it obviously doesn't matter to you that much so
why the rush to deprecate it?

> +1 on doing a deprecation in 3.4.

-1 on any deprecation without a clear plan for a better syntax. Simply
changing the semantics of the current syntax would bring in who knows
how many off-by-one errors for virtually no benefit.

Personally I think that negative slicing and indexing are both bad
ideas. I've had many bugs from the wraparound behaviour of both and
I've never had a situation where the wraparound was useful in itself
(if it worked using modulo arithmetic then there would at least be
some uses - but it does not).

Matlab has a much better way of handling this with the end keyword:

% chop last n elements off:
a_chopped = a(1:end-n)

This works even when n is zero because it's not conflating integer
arithmetic with indexing relative to the end.


Oscar


More information about the Python-ideas mailing list