Possible improvement to slice opperations.

[Ron Adam]

Patrick Maupin wrote:

> I previously wrote (in response to a query from Ron Adam):
> 
> 
>>In any case, you asked for a rationale.  I'll give you mine:
>>
>>
>>>>>L = range(10)
>>>>>L[3:len(L):-1] == [L[i] for i in range(3,len(L),-1)]
>>
>>True
>>
> 
> After eating supper, I just realized that I could probably make my
> point a bit clearer with a slightly longer example:
> 
> 
>>>>L = range(10)
>>>>for stride in [-3, -2, -1, 1, 2, 3]:
> 
> ...     for start in range(len(L)):
> ...         for end in range(len(L)):
> ...             P = L[start:end:stride]
> ...             #Q = [L[i] for i in range(start, end, stride)]

                   Q = [L[i] for i in range(start, end)][::stride]

> ...             assert P == Q


With the changed line above it will pass with the example nxlist type.

The result is different because the method is different.  So in order 
for this test to not give an assert, the same order needs to be used.


> This should never fail with an assertion error.  You will note that it
> shows that, for non-negative start and end values, slicing behavior is
> _exactly_ like extended range behavior.  

Yes, and it passes for negative start and end values as well.


> I cannot imagine that the
> behavior of range() could be made any more intuitive than it already
> is.  

If range were also changed.. (I'm not suggesting it should be) 
range(0,10,-1), would count down from 10 to zero. The sign of the step 
would determine which side to iterate from.

I think they are both fairly equivalent as far as intuitiveness. But I 
think I agree, changing both range and slice is probably out of the 
question.


> I personally feel that your proposed change makes slice() less
> intuitive on its own, but even if I did not feel that way, your way
> would have to be SIGNIFICANTLY better than the current way to make it
> worthwhile to make slice() behavior differ from that of range().

Well I did post it as a "possible" improvement, meaning I wasn't sure. 
And did ask for opinions.  This was the type of reply I was looking for. 
Thanks for replying, and for taking a serious look. :-)


> In my initial skimming of your post, I originally thought you were
> referring to negative start and end values.  Negative start and end
> values will sometimes cause issues, but the utility of their current
> implementation far outweighs the few corner cases which (as I mentioned
> in an earlier post) sometimes need some special case logic to deal
> with.

I was referring to both, it seemed to me that my suggestion had enough 
good things in it that it would be worth asking others if it was 
feasible, and also if it were desirable.  In any case, it's an 
interesting topic and looks like it could have been a valid alternative 
if it were done this way from the start.  Probably isn't good enough to 
change now.

Thanks again, this pretty much explains why slices opperate the way they 
do.  And it explains why the edge case's happen as well I think.

Cheers,
Ron



> Regards,
> Pat