Possible improvement to slice opperations.

[Bengt Richter]

On Mon, 5 Sep 2005 22:56:29 +0200, "Fredrik Lundh" <fredrik at pythonware.com> wrote:

>Bengt Richter wrote:
>
>>>as long as you have people that insist that their original misunderstandings
>>>are the only correct way to model the real world, and that all observed
>>>inconsistencies in their models are caused by bugs in the real world, you'll
>>>end up with threads like this.
>>>
>> OTOH, ISTM we must be careful not to label an alternate alpha-version
>> "way to model the real world" as a "misunderstanding" just because it is alpha,
>> and bugs are apparent ;-)
>
>in my post, "the real world" is the existing Python implementation.  what
>theoretical construct are you discussing?
>
I guess I was talking about a "real world" of abstractions (if that is not an oxymoron ;-)
re sequences and slice access methods, of which the existing python implementation
provides a concrete example of one "model" and Ron's efforts provide some attempts at
an alternative "model". Of course, as far as the concrete "real world" goes, python does what
it does, and a model of _that_ that doesn't fit is a real misunderstanding ;-)

BTW, how did relative slice semantics strike you? They could live along side normal ones
by prefixing the slice brackets with a '.', like r.[3:-2] for 2 (abs(-2)) elements
leftwards(-2<0) starting with r[3]. The logic for None defaults and non-1 steps and
guaranteeing legal ranges is messy, but otherwise UIAM

     r.[start:count] == r[start:start+count:-(count<0) or 1]

allowing signed start and count values. IMO r[start] is easy for newbies
to understand as a starting element, whether from end or beginning, and
an absolute value of count is easy, with the sign saying which direction
to scan from the start element, irrespective of how the latter was specified.

Regards,
Bengt Richter