On 10/28/2013 01:20 PM, Oscar Benjamin wrote:
On 28 October 2013 15:04, Brett Cannon <brett@python.org> wrote:
I'm not saying not to talk to them, but I also don't think we should necessarily not change it because no one uses it either. If it's wide spread then sure, we just live with it. It's always a balancing act of fixing for future code vs. pain of current code. I'm just saying we shouldn't dismiss changing this out of hand because you are so far the only person who has relied on this.
Anyone who has used negative strides and non-default start/stop is relying on it. It has been a core language feature since long before I started using Python.
I have code that relies on this.
Also I'm not the only person to point out that a more common problem is with wraparound when doing something like a[:n]. That is a more significant problem with slicing and I don't understand why the emphasis here is all on the negative strides rather then negative indexing. Using negative indices to mean "from the end" is a mistake and it leads to things like this:
--> a = 'abcdefg' --> for n in reversed(range(7)): ... print(n, a[:-n]) ... 6 a 5 ab 4 abc 3 abcd 2 abcde 1 abcdef 0
I've been bitten by this more than once. :(
Something like the matlab/pike syntax would fix these problems as well as making it possible to use the same indices for negative stride slices. That would be worth a deprecation process in my opinion. The specific suggestion so far does not have enough of an advantage to justify breaking anyone's code IMO.
+1
As for the rush, it's because 3.4b1 is approaching and if this slips to 3.5 that's 1.5 years of deprecation time lost for something that doesn't have a syntactic break to help you discover the change in semantics.
The difference between 7.5 years and 6.0 years of deprecation time don't seem that significant to me. Besides, can't we add the deprecation to the docs whenever? -- ~Ethan~