Actually about PEP 202 (listcomps), not (was RE: [Python-Dev] Lukewarm about range literals) (original) (raw)

Tim Peters tim_one@email.msn.com
Tue, 29 Aug 2000 05:45:24 -0400

[/F]

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

Don't know about that, but it doesn't appear to work as well as was hoped.

[Tim]

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?

Sure looks like it to me. The Haskell designers explicitly credited SETL for list comprehensions, but I don't know that they do for this gimmick too. Of course Haskell's "infinite" list builders weren't in SETL, and, indeed, expressions like [1..] are pretty common in Haskell programs. One of the prettiest programs ever in any language ever:

primes = sieve [2..] where sieve (x:xs) = x : sieve [n | n <- xs, n mod x /= 0]

which defines the list of all primes.

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

It was way ahead of its time. Still is! Check out its general loop construct, though -- now that's a kitchen sink. Guido mentioned that ABC's Lambert Meertens spent a year's sabbatical at NYU when SETL was in its heyday, and I figure that's where ABC got quantifiers in boolean expressions (if each x in list has p(x); if no x in list has p(x); if some x in list has p(x)). Have always wondered why Python didn't have that too; I ask that every year, but so far Guido has never answered it .

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: ...

You left off the last sentence from the first time you posted this:

is there any special reason why we cannot use colon instead of "for"?

Guido then said we couldn't use a colon because that would make [x : y] too hard to parse, because range literals were of the same form. Thomas went on to point out that it's worse than that, it's truly ambiguous.

Now I expect you prefaced this with "now that the range literals are gone" expecting that everyone would just remember all that . Whether they did or not, now they should.

I counted two replies beyond those. One from Peter Schneider-Kamp was really selling another variant. The other from Marc-Andre Lemburg argued that while the shorthand is convenient for mathematicians, "I doubt that CP4E users get the grasp of this".

Did I miss anything?

Since Guido didn't chime in again, I assumed he was happy with how things stood. I further assume he picked on a grammar technicality to begin with because that's the way he usually shoots down a proposal he doesn't want to argue about -- "no new keywords" has served him extremely well that way . That is, I doubt that "now that the range literals are gone" (if indeed they are!) will make any difference to him, and with the release one week away he'd have to get real excited real fast.

I haven't said anything about it, but I'm with Marc-Andre on this: sets were extremely heavily used in SETL, and brevity in their expression was a great virtue there because of it. listcomps won't be that heavily used in Python, and I think it's downright Pythonic to leave them wordy in order to discourage fat hairy listcomp expressions. They've been checked in for quite a while now, and I like them fine as they are in practice.

I've also got emails like this one in pvt:

The current explanation "[for and if clauses] nest in the same way
for loops and if statements nest now." is pretty clear and easy to
remember.

That's important too, because despite pockets of hysteria to the contrary on c.l.py, this is still Python. When I first saw your first example:

 [n : n in range(100)]

I immediately read "n in range(100)" as a true/false expression, because that's what it is in 1.6 unless immediately preceded by "for". The current syntax preserves that. Saving two characters (":" vs "for") isn't worth it in Python. The vertical bar would be "worth it" to me, because that's what's used in SETL, Haskell and common mathematical practice for "such that". Alas, as Guido is sure to point out, that's too hard to parse <0.9 wink>.

consider-it-channeled-unless-he-thunders-back-ly y'rs - tim