Possible improvement to slice opperations.

[Ron Adam]

Terry Reedy wrote:
> "Ron Adam" <rrr at ronadam.com> wrote in message 
> news:FRISe.13089$xl6.6814 at tornado.tampabay.rr.com...
> 
>>Slicing is one of the best features of Python in my opinion, but
>>when you try to use negative index's and or negative step increments
>>it can be tricky and lead to unexpected results.
>>
>>This topic has come up fairly often on comp.lang.python, and often times, 
>>the responses include:
>>    * Beginners should avoid negative extended slices.
>>    * Slices with negative step increments are for advanced
>>      python programmers.
>>    * It's not broke if you look at it in a different way.
>>    * You should do it a different way.
> 
> 
> You omitted the slice-specific response I gave before and repeat here with 
> more detail by quoting from What's New in Python 2.3.
> http://www.python.org/doc/2.3/whatsnew/section-slices.html
> "
> 15 Extended Slices
> Ever since Python 1.4, the slicing syntax has supported an optional third 
> ``step'' or ``stride'' argument. For example, these are all legal Python 
> syntax: L[1:10:2], L[:-1:1], L[::-1]. This was added to Python at the 
> request of the developers of Numerical Python, which uses the third 
> argument extensively. However, Python's built-in list, tuple, and string 
> sequence types have never supported this feature, raising a TypeError if 
> you tried it.
> "

I didn't omit anything,  I previously gave examples of using various 
forms of slices with the intent of showing how some of those forms are 
not symmetrical and difficult to understand.  And then you explained 
more precisely how those slices were indexed.

It would be useful to do a side by side comparison of those cases and 
similar ones to this new method.  Then maybe the benefits of making the 
changes I'm suggesting will be clearer.

I looked at the documents in Numerical Python.  From what I could tell, 
it uses the form L[::-1] quite a bit, which will still work *exactly* as 
it does now.  There were no examples of partial negative step 
operations, so I couldn't determine if/how they are used.  I'll install 
it and experiment with it and see if/how it works with Numerical Python.

After Python 3000 is released Numerical Python will need to be updated 
even without these changes.  But it is a good idea to consult with the 
Numerical Python developers on this.


> Again, extended slices were probably designed by and certainly designed for 
> Numerical Python and for 7 years were used at least mainly by Numerical 
> Python.  They were not designed for other users like you.  The responses 
> you summarized and distain pretty much all derive from this history.

Other users like me?  And what kind of user am I?

Is it really a good idea to maintain that some things shouldn't be done 
by some, but is ok for others?

I think you mean to say that extended slices with negative strides, 
should only (or primarily) be used with Numerical Python.  I however 
disagree with that view. I think they have a broader range of uses.


> So, I am pretty sure that changes to the core would have to be upwards 
> compatible with current usage.  ...

This is why I said these changes probably couldn't be made before Python 
  3000.  It is upward (backward?) compatible for the majority of use 
cases, all direct indexing operations, and all positive extended slices. 
  In Python's library, only negative extended slices will need to be 
adjusted.  As far as I could tell there are no partial negative strides 
cases that will need to be adjusted.  I wish there was a few, because 
then I could show how this would improve those cases.

Now even though this suggestion may be sound, that alone isn't reason 
enough to include it in Python 3000.  It would need clear use case 
benefits and support by users as well as support from Guido.

At this point, I'm only trying to clarify the issues and develop working 
examples.

> ... On the other hand, your nxlist subclass of list seems to work
> pretty well now. The 2.2+ ability to do this sort of thing is what
> type subclassing was made for.

Yes, it does work well, (so far)  :-)  Which is the motivation for me 
posting it.  Lets make it better.


> Or one could just write an extended slice function similar to your .normslc 
> method.  I might even use such a thing one day.

Unfortunately one can not sub-class slice objects directly.  And the ':' 
in a slice index isn't a true operator with it's own methods.  So 
changing existing slice behavior will require changing the core.  But 
for now I will write a function and a complete list sub-class and post 
it here.

Cheers,
Ron



> Terry J. Reedy
> 
>