Possible improvement to slice opperations.

[Ron Adam]

Patrick Maupin wrote:

>>After considering several alternatives and trying out a few ideas with a
>>  modified list object Bengt Richter posted, (Thank You), I think I've
>>found a way to make slice operation (especially far end indexing)
>>symmetrical and more consistent.
> 
> 
> I don't know that it makes it more consistent.  I could be persuaded,
> but it would have to be by real-life examples with calculated slice
> indices and stride.  I do this thing all the time, and find the current
> rules simple and very consistent.  Occasionally, I might wish that
> things were a little different, but there is always a workaround.  I
> would have to see some real code examples, of sufficient scope to see
> that there are fewer workarounds with this proposal than with the
> current implementation.

I'll post a few examples once I'm sure the list object works correctly 
and then you can play around with it and try it out as well.

> FWIW, there is a reasonable workaround for the case where the indices
> might be negative and you would like zero or greater to mean 'end of
> list'.  If "x" is the index variable, you can use the expression (x<0
> and x or None) for the index value in the slice.  If you find yourself
> doing this often, you can write a little function for it -- def
> EndIndex(x): return x<0 and x or None.

Thanks, this is a good example.

Yes it does remove the need for a work around in those cases.

You still need to check for cases where you may cross the -1,0 boundary 
while incrementing or decrementing an index.  But that is an expected 
condition and easily handled with an 'if' or 'for' loop.


> But in real code, I fear you might need a similar helper function for
> similar issues with your change.  I just don't know what those are
> without more thought.
> 
> Regards,
> Pat

Thanks for the feedback, it was helpful.

Cheers,
Ron