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

[Tim Peters]

[/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 <wink>.

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