map, filter, lambda, list comprehensions (was RE: parameter undefined in procedure)

Tim Peters tim_one at email.msn.com
Sun Feb 27 19:40:19 EST 2000


[Evan Simpson]
> ... I actually think I "get" list comprehensions now.  They describe
> a list by giving the expression used to compute an element, generator(s)
> which produce the arguments to the expression, and an optional filter
> expression.  Right?

Right, after changing "filter expression" to "filter expression(s)".

> So the difficulty you describe above is the problem of Pythonically
> expressing things like 'for x, y in map(None, s1, s2)' versus the
> cartesian 'for x in s1, for y in s2'.  Despite my utter lack of language
> implementation experience, I can never resist proposing a syntax, so here
> goes:

I'd play along, except this game was played for months in '98 already, and
if DejaNews ever recovers its memory you can just read what Guido decreed
<wink>.

What Greg Ewing actually implemented is (IIRC) a compatible subset.  Here
are examples taken from the docs for Greg's patch:

    numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    fruit = ["Apple", "Banana", "Pear"]
    mult3 = [3 * x for x in numbers]
    evens = [x for x in numbers if x % 2 == 0]
    crossprod = [(x, y) for x in numbers for y in fruits]

What's missing is lockstep (parallel) iteration.  IIRC, Guido settled on
some use of the semicolon for that.  Once that's in, the door is open to a
bit more syntax to get at the loop index too; e.g., perhaps

    for i in *; x in seq:

acting like the old

   for i indexing x in seq:

proposal that died for requiring a new keyword.

> ...
> How's this:
>
> [x * y for x, y in {range(3), range(3)}] == [0, 1, 4]

   for x, y in (range(3), range(3)):

already has a different meaning in Python (one that raises a runtime
exception), and using curly braces instead requires too much lookahead in
the parser (not to mention people) to distiguish it from a dict.

> [x * y for x, y in {range(3)}{range(3)}] == [0, 0, 0, 0, 1, 2, 0, 2, 4]

Similarly.

> ...
> I would expect assignment to an iteration index to be a
> compile-time error.

I would not, as Python explicitly allows that today.

> Well, *I* like it, anyway :-)

The functionality or your syntax <wink>?

patched-out-ly y'rs  - tim






More information about the Python-list mailing list