[Python-Dev] Lukewarm about range literals

[Fredrik Lundh]

tim peters wrote:
> Charles likes slices.  Me too!  I *love* them.  But as a standalone notation
> (i.e., not as a subscript), part of the glory of slicing breaks down:  for
> the list a, a[:] makes good sense, but when *iterating* over a,  it's
> suddenly [:len(a)] because there's no context to supply a correct upper
> bound.

agreed.  ranges and slices are two different things.  giving
them the same syntax is a lousy idea.

> Post 2.0, who knows.  I'm not convinced Python actually needs another
> arithmetic-progression *list* notation.  If it does, I've always been fond
> of Haskell's range literals (but note that they include the endpoint):
> 
> Prelude> [1..10]
> [1,2,3,4,5,6,7,8,9,10]
> Prelude> [1, 3 .. 10]
> [1,3,5,7,9]

isn't that taken from SETL?

(the more I look at SETL, the more Pythonic it looks.  not too
bad for something that was designed in the late sixties ;-)

talking about SETL, now that the range literals are gone, how
about revisiting an old proposal:

    "...personally, I prefer their "tuple former" syntax over the the
    current PEP202 proposal:

        [expression : iterator]

        [n : n in range(100)]
        [(x**2, x) : x in range(1, 6)]
        [a : a in y if a > 5]

    (all examples are slightly pythonified; most notably, they
    use "|" or "st" (such that) instead of "if")

    the expression can be omitted if it's the same thing as the
    loop variable, *and* there's at least one "if" clause:

        [a in y if a > 5]

    also note that their "for-in" statement can take qualifiers:

        for a in y if a > 5:
            ...

</F>