[Python-Dev] Lukewarm about range literals (original) (raw)

Tim Peters tim_one@email.msn.com
Wed, 30 Aug 2000 18:54:25 -0400

[Skip Montanaro]

... What we really want I think is something that evokes the following in the mind of the reader

for i from START to END incrementing by STEP: without gobbling up all those keywords.

Note that they needn't be keywords, though, any more than "as" became a keyword in the new "import x as y". I love the Haskell notation in Haskell because it fits so nicely with "infinite" lists there too. I'm not sure about in Python -- 100s of languages have straightforward integer index generation, and Python's range(len(seq)) is hard to see as much more than gratuitous novelty when viewed against that background.

for i = 1 to 10:           #  1 to 10 inclusive
for i = 10 to 1 by -1:     #  10 down to 1 inclusive
for i = 1 upto 10:         #  1 to 9 inclusive
for i = 10 upto 1 by -1:   #  10 down to 2 inclusive

are all implementable right now without new keywords, and would pretty much have to be "efficient" from the start because they make no pretense at being just one instance of an infinitely extensible object iteration protocol. They are what they are, and that's it -- simplicity isn't always a bad thing .

for i in [START..END,STEP]: for i in [START:END:STEP]: for i in [START..END:STEP]:

The difference in easy readability should squawk for itself.

for i in 0 ..! len(a): a[i] += 1

Looks like everybody hates that, and that's understandable, but I can't imagine why

 for in 0 .. len(a)-1:

isn't equally hated! Requiring "-1" in the most common case is simply bad design. Check out the Python-derivative CORBAscript, where Python's "range" was redefined to include the endpoint. Virtually every program I've seen in it bristles with ugly

for i in range(len(a)-1)

lines. Yuck.

but-back-to-2.0-ly y'rs - tim