[Python-ideas] [Python-Dev] Inclusive Range

[Carl M. Johnson]

On Tue, Oct 5, 2010 at 1:05 AM, Masklinn <masklinn at masklinn.net> wrote:

>> (if we were creating a new language that was 1 indexed and range
>> was likewise adjusted), the list [1] would be range(1), and the empty
>> list would be range(0), so the whole issue could be neatly
>> sidestepped. :-)
> I fail to see what gets sidestepped there. Ignored at best.

He was trying to be language neutral by writing using < and <= but
that's part of his problem. He's too much of a mathematician.
Rewriting things so that they don't use < or <= at all is the best way
to explain things to a non-math person. If you say "range(1, 5) gives
a range from 1 to 5" your explanation doesn't have to use < or <= at
all. This is unlike a C-like language where you would write int i=2;
i<12; i++. So the question of what mathematics "really" underlies it
can be sidestepped by using a language that many people know better
than the language of mathematics: the English language.

>> As for l == l[:x] + l[x:y] + l[y:] where y > x, I think a case can be
>> made that it would be less confusing as l == l[:x] + l[x+1:y] +
>> l[y+1:], since you don't want to start again with x or y.
> Why not?

Because (speaking naively) I already FizzBuzzed the x-th element
before. I don't want to double FizzBuzz it. So that means I should
start up again with the +1 element.

>> You just
>> ended at x. When you pick up again, you want to start at x+1 and y+1
>> so that you don't get the x-th and y-th elements again. ;-)
> Yes indeed, as you demonstrate here closed ranges greatly complexify the code one has to write compared to half-closed ranges.

Yup. TANSTAAFL. That's why we shouldn't actually bother to change
things: you lose on the backend what you gain on the frontend. I'm
just curious about whether starting programmers have a strong
preference for one or the other convention or whether both are
confusing.