Specify start and length, beside start and end, in slices

[Noam Raphael]

Hello,

Terry Reedy wrote:
> "Noam Raphael" <noamr at correctme.users.sourcephorge.net> wrote in message
> news:c8l3s3$27o$1 at news.iucc.ac.il...
> 
> 
>>Many times I find myself asking for a slice of a specific length, and
>>writing something like l[12345:12345+10].
>>This happens both in interactive use and when writing Python programs,
>>where I have to write an expression twice (or use a temporary variable).
> 
> 
> With an expression, I'd go for the temp var.
> 
> 
>>Wouldn't it be nice if the Python grammar had supported this frequent
>>use?
> 
> 
> I take this as 'directly support' versus the current indirect support via
> start+len.
> My answer: superficially (in isolation) yes, but overall, in the context of
> Python's somewhat minimalistic grammar/syntax, no.  Two ways to slice might
> easily be seen as one too many.

I agree that Python should be kept easy to read and understand. However, 
it doesn't mean that there's only one way to do everything. An example 
(it's even from slices): the Numeric people asked for the "..." token 
and got it, even though you can live without it - it simply makes your 
life easier.

> In addition, the rationale for this, your
> favorite little addition, would admit perhaps 50 others like it.
> 
> 
>>My idea is that the expression above might be expressed as l[12345:>10].
> 
> 
> Sorry, this strike me as ugly, too much like and easily confused with
> l[12345:-10], and too much looking like a syntax error.
Well, of course, it *is* a syntax error right now. As for what it looks 
like - I can't argue with what it looks like to you, but since '>' is 
generally perceived as having something to do with "go in the right 
direction", I think that l[12345:>10] can easily be read as "start from 
12345, and take 10 steps to the right. Take all the items you passed over."
> 
> Given that some other languages slice with (start,len) arguments (but not
> then, that I remember or know of, also with a start,stop option), I am
> *sure* that Guido thought carefully about the issue.  A plus with his
> choice is ability to offset (index) from the end *without* calling the len
> function.
> 
I think that the fact that other languages use (start, len) quite 
contradicts your assumption that only 50 other people would like it. I 
don't see what brings you to think that you represent 99.99 percent of 
Python users.
I like Python's slicing very much, and I agree that given only one 
slicing method, (start, end) should be chosen, but what's wrong with 
adding another?
> 
>>This change, as far as I can see, is quite small: it affects only the
>>grammar and byte-compiling, and has no side effects.
> 
> 
> Except the cognitive dissonance of two *almost* identical syntaxes and the
> flood of other 'small', 'no side effect' change requests.
> 
Why not judge each 'small, no side effect' change request for its own 
sake? Do you think that Python should only undergo big and complex changes?
> 
>>Well, what do you think? I would like to hear your comments.
> 
> 
> Your wish ...
Yes, I do like to hear other opinions. Perhaps *you* could have been a 
bit more open to hear them...
> 
> Terry J. Reedy
> 
> 
Noam Raphael