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

[Rob Cliffe]

I'd like to throw in an idea.  Not sure how serious it is (prepared to 
be shot down in flames :-) ), just want to be sure that all 
possibilities are examined.
With positive strides, "start" is inclusive, "end" is exclusive".
Suppose that with negative strides, "start" were exclusive and "end" was 
inclusive.
(I.e. the "lower" bound was always inclusive and the "upper" bound was 
always exclusive.)
Then "abcde"[:2:-1] would be "edc", not "ed".
Then "abcde"[:1:-1] would be "edcb", not "edc".
Then "abcde"[:0:-1] would be "edcba".
I think this fits in with Tim Peters' concept of characters between 
positions, e.g. "abcde"[3:0:-1] would be "cba" (not "dcb" as at 
present), i.e. the characters between positions 0 and 3.
Rob Cliffe

On 27/10/2013 17:04, Guido van Rossum wrote:
> In the comments of 
> http://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing.html 
> there were some complaints about the interpretation of the bounds for 
> negative strides, and I have to admin it feels wrong. Where did we go 
> wrong? For example,
>
> "abcde"[::-1] == "edcba"
>
> as you'd expect, but there is no number you can put as the second 
> bound to get the same result:
>
> "abcde"[:1:-1] == "edc"
> "abcde"[:0:-1] == "edcb"
>
> but
>
> "abcde":-1:-1] == ""
>
> I'm guessing it all comes from the semantics I assigned to negative 
> stride for range() long ago, unthinkingly combined with the rules for 
> negative indices.
>
> Are we stuck with this forever? If we want to fix this in Python 4 
> we'd have to start deprecating negative stride with non-empty 
> lower/upper bounds now. And we'd have to start deprecating negative 
> step for range() altogether, recommending reversed(range(lower, 
> upper)) instead.
>
> Thoughts? Is NumPy also affected?
>
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2242 / Virus Database: 3222/6285 - Release Date: 10/27/13
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131028/6445622d/attachment.html>