Proposed PEP: New style indexing, was Re: Bug in slice type

[Paul Rubin]

Bryan Olson <fakeaddress at nowhere.org> writes:
>      seq[3 : -4]
> 
> we write:
> 
>      seq[3 ; $ - 4]

+1

> When square-brackets appear within other square-brackets, the
> inner-most bracket-pair determines which sequence '$' describes.
> (Perhaps '$$' should be the length of the next containing
> bracket pair, and '$$$' the next-out and...?)

Not sure.  $1, $2, etc. might be better, or $<tag> like in regexps, etc.

> So really seq[-2] should be out-of-bounds. Alas, that would
> break way too much code. For now, simple indexing with a
> negative subscript (and no '$') should continue to index from
> the high end, as a deprecated feature. The presence of '$'
> always indicates new-style slicing, so a programmer who needs a
> negative index to trigger a range error can write:
> 
>      seq[($ - $) + index]

+1

> Commas are already in use to form tuples, and we let them do
> just that. A slice is a subscript that is a tuple (or perhaps we
> should allow any sequence). We could just as well write:
> 
>      index_tuple = (start, stop, step)
>      sequence[index_tuple]

Hmm, tuples are hashable and are already valid indices to mapping
objects like dictionaries.  Having slices means an object can
implement both the mapping and sequence interfaces.  Whether that's
worth caring about, I don't know.