The updated patch i submitted included the following changes:
    1. More explanation of listcomps in the docs.
    2. Modified test cases to use [(x, y) for ...].
    3. Added a test case to ensure [x, y for ...] is a SyntaxError.
    4. Cleaned up grammar by adding a "listmaker" rule.
    5. Temporary local name is now "__1__" instead of "1".
    6. Look up "append" once, outside the loop, instead of inside.

The optimization in #6, which is one of the things you were worried about, produces a noticeable speedup (up to 20% on very long lists).

Skip, i updated my tree & it looks like not all the patch got checked in.  Did you check in Doc/tut/tut.tex also?

This one's for Tim to thaw later.

I actually like this a lot (am running with it myself!), but the patch needs to be reworked so that it requires [(x,x) for x in ...] instead of allowing [x,x for x in ...].

It also may require integration with the range literals syntax, but that should be relatively minor.

Go for it!

(This must be unique -- the PEP still hasn't been finished, and the code is already accepted. :-)

Note: some changes will be necessary again to implement range literals!
But that's now up to the range literals patch...

The new patch is a CVS diff, which makes it kind of hard to apply (it'll only apply with the right GNU patch, with 'POSIXLY_CORRECT' defined, and with the moon in the right phase, which it currently isn't, apparently ;)
POSIXLY_CORRECT also has some other effects, like that patch refuses to create new files :P Can I ask for a normal recursive-diff so I can recreate the range-list-literal patch relative to this one ?

Adjusting range literals to fit is not a problem. However, is this implementation really accepted ? I find the way it generates code, well, scary. Almost appalling :) It creates a new list (as a new local variable, with a numeric name), loads the list's append method, and calls the append method for each iteration of the listcomp. Is that really the best way to do it ?

IIRC, Greg proposed a new bytecode that reaches down X items on the stack, which should be a list, and append to it the X-1 items above it. This requires a new opcode, but is more efficient, and cleans up some of the mess the current patch requires.

This new patch is simply an update to keep up with the recent ANSIfication of the Python source...

Okay, the grammar stuff is a little bit beyond me and I don't have the time to investigate it fully at the moment.  
*** Perhaps someone can give me a little direction... ***

(I submitted an update last night, but it appears not to have "taken".  Is that because I'm changing the status from "rejected" to "open".)

This is a corrected patch from Ka-Ping Yee that adds the parens requirement for tuples in the leading expression, e.g.: 

   [(x,x**2) for x in range(5)]

instead of Greg Ewing's original syntax which allowed

   [x,x**2 for x in range(5)]


    

I don't think that's a problem.  It's no worse than the code generated for a loop written by a user to do the same thing. If it turns out that a more efficient code generation scheme can be developed, that can wait.

what update patch you submitted?  who are you?  your comment is attributed to none.  if you have a new patch for list comprehensions, please make it relative to the current cvs tree and send it to me (skip@mojam.com).

I'm pretty sure i know how to do this (just
replace the list-making clause of the "atom:"
production with:

'[' [test [list_iter | ',' testlist]] ']'

then update com_list_constructor and the LSQB
clause of com_atom appropriately), but i still
much prefer a style that uses a separator --
if not between clauses, then at least between
the expression and the conditions.

My favourite: [x*2, for x in spam, if x > 3]

The separator after the expression can be comma,
semicolon, or omitted; the separator between
conditions can be any of these as well as colon.
(Greg's original patch chooses "nothing-nothing";
i choose "comma-comma".)

The results of Greg Wilson's survey may also be
useful.  Once a decision is made, it should be 
easy to adjust the grammar for any of these
twelve possibilities.

So all we need is a Pronouncement. :)

Sorry, sorry!  That last comment describing the patch was mine (this is Ping).  Either SourceForge forgot i was logged in or i forgot to log in.  I was responding to Thomas' comment about the code-generation seeming "scary".

I just checked, and the current version (1.113) of Doc/tut/tut.tex still does not contain the changes which were part of that patch.  (That is, the section on list comprehensions does not have any examples showing the use of "if" clauses.)  I don't know why it didn't get applied when the rest of the patch did... but could you cut out that part of the patch, apply and check it in?

Thanks!