Possible improvement to slice opperations.

[Ron Adam]

Bengt Richter wrote:

> Then the question is, do we need sugar for reversed(x.[a:b])
> or list(reversed(x.[a:b])) for the right hand side of a statement,
> and do we want to to use both kinds of intervals in slice assignment?
> (maybe and yes ;-)

Yes, I think this is the better way to do it, as this address's the 
underlying causes instead of treating the symptoms.


> The reason for yes is that it solves the which-gap problem in assigning to [a:a]
> if you define [a, a) as an empty interval to the left of a and (a, a] as an empty
> interval to the right of a, sort of like +0 and -0 in half-open intervals ;-)
> Replacing the empty interval does the insertion on the side you want ;-)
 >
> I am choosing the convention to stay compatible with python's current behaviour,
> even though I'm not sure what the math world says about a<x<=a vs a<=x<a as
> different-in-some-sense intervals. I guess the intervals as point sets are the same,
> but the interval definitions are different...

Not sure either.  I think intervals is an important concept and enabling 
python to work with them would be good if it could be done in a simple 
and consistent way.  This extends a lot further than just slice 
operations because of the relationship between ...

      for x in range()  ->  slice(range)


So defining an interval object that can be used as an iterator in a for 
loop might be the beginning, and then finally slice with an alternate 
syntax to an abbreviated form.  So then you would have the relationship 
of...

     for x in interval() -> slice(interval)


> Other than the a:a distinction, in terms of integers and UIAM
>     .[a:b]
> is just sugar for
>     [a+1:b+1]
> but the sugar is nice, and the slice assignment to either side is nicer.

Wouldn't that be [a:b+1] ?

As sugar the index's are translated at compile time, it may run into the 
current edge case indexing problems.  So it will most likely need to be 
an actual interval object, with an alternative syntax to use it.

> I'll deal with the subsetting another time ...

No hurry, this isn't a hack it out because "the boss wants it on his 
desk Monday" situation.  ;-)

> Regards,
> Bengt Richter

Cheers,
Ron