[Python-Dev] list comprehensions again...
Tue, 11 Jul 2000 19:22:03 +0200
On Tue, Jul 11, 2000 at 12:52:43PM -0500, Guido van Rossum wrote:
> Ideally, list comprehensions should support both parallel and nested
> for loops, but I'm not sure how to decide to parse them if they both
> occur. E.g. what is this?
> [(x,y+z) for x in (1,2,3,4,5,6); for y in "abc" for z in "de"]
Well, listcomprehensions are currently almost a simple rewrite, so this is
fairly easy to parse: the ; binds more tightly than the last 'for', and
'for' loops and 'if' branches parse left-to-right without possibilities of
> But is that the most useful? And how do you write the other grouping?
> I mean:
> (for x; for y) (for z)
> which could yield:
> [(1, "ad"), (1, "ae"), (2, "bd"), (2, "be"), (3, "cd"), (3, "ce")]
This might be a problem. Also, even providing the 'nested for' in
listcomprehensions might be a problem, for exactly the reason you yourself
showed: it's not that easy to see what it actually does.
Can we get away with not including the nested-for syntax ? I mean, "don't do
that then" is something that really appeals to me, and I think it applies
here: If you want nested-for loops in creating a list, use a real for loop
Also, on 4th or 5th pass, I'm still not sure about the whole list
comprehensions syntax... I know what problem they are supposed to solve, and
I think they succeed in that. But the syntax is pretty ambiguous, and not
too pythonic at that. For instance, the endless mixing possibilities of
'for' and 'if' without delimiters or ways to group them can be pretty
confusing. Some documentation on that might help, though. Also, it would be
nice if list comprehensions could be used to initialize *part* of a list,
something like this:
['a', 'b', c for c in ['C', 'D', 'E'], 'f', 'g']
(which would create ['a', 'b', 'C', 'D', 'E', 'f', 'g'])
But that creates a legion of other confusalities... Perhaps adding a
new/different delimiter to list comprehensions would be a good idea ? :P
Disclaimer, though: I didn't follow the list-comprehension discussions on
python-list, last year, that closely. I noticed the syntax and thought "that
cool.", but that's about it. Was any other syntax proposed ?
> A more practical question: if we're going to introduce [::], list
> comprehensions, and parallel for loops, what would be the best way to
> introduce the patches so that each patch changes as little as possible
> of the code introduced by the previous patch?
parallel-for-loops -> list comprehensions -> range-literals
Unless list comprehensions do not adopt the parallel for loop syntax, in
which case the order isn't that important. They don't really touch in that
much places, not even the range-literals and list comprehensions patch. The
Grammar and a single line in compile.c, if I recall correctly. The rest is
just offset and fluff.
Thomas Wouters <firstname.lastname@example.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!