A suggestion for a possible Python module

[Terry Reedy]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:nnl9a.7858$pG1.194289 at news1.tin.it...
> Terry Reedy wrote:
> > As near as I can tell, the 19 February 2003 2.3a2 Ref Man, Section
> > 5.3.3 Slicings, (on python.org) has not been updated to specify
the
> > long_slice behavior when *not* used as a dict key but used for seq
> > access.  If so, there is no way to tell if behavior above is
intended
> > or is a bug (except by analogy with Numeric behavior, which I am
not
> > familiar with).
>
> I think a more familiar analogy, although not explicitly pointed
> out in the language reference AFAIK,

When SF lets me log in againg, I will open a bug report noting the
non-update and suggesting possible inclusion of the analogy.

> is that slices are meant to
> correspond to the same indices that range or xrange would produce
> when called with the same start, stop and step parameters (net
> of issues with missing or negative parameters, or slicings of a
> too-short sequence).
>
> >>> range(7,2,-1)
> [7, 6, 5, 4, 3]
> >>>
>
> It would be weird, astonishing, and unPythonic in the extreme if
> (assuming 'whatever' is a sequence with a length of at least 8)
> whatever[7:2:-1] didn't produce a subsequence of 'whatever' that
> starts with whatever[7] and end with whatever[3], NOT reaching all
> the way to whatever[2] -- just like whatever[2:7] produces a
> subsequence that starts with whatever[2] and ends with whatever[6],
> not reaching all the way to whatever[7].

OK:  s[hi:lo:-step] selects the same items that
reversed(s)[lo:hi:step] would, but without reversing the items.  In
other words, a negative step causes the slice, in effect, to work from
right to left (building the result from right to left also) instead of
the normal left to right.  This is perhaps easier to see with slices
from definitely finite sequences than range()s selected from
system-dependently bounded integers.

> so, whatever[start:stop] = whatever[stop:start:-1] "CANNOT:
> reverse a subsequence in place without breaking all kinds of
> expected regularities between slices and range/xrange...!

I agree now.  I will include in the rationale for the slice reverse
proposal.

Terry J. Reedy