[Patches] [Patch #100654] list comprehensions in Python (for 2.0)
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 14 Aug 2000 07:50:18 -0700
Patch #100654 has been updated.
Project:
Category: core (C code)
Status: Closed
Summary: list comprehensions in Python (for 2.0)
Follow-Ups:
Date: 2000-Jun-28 07:07
By: gvanrossum
Comment:
This one's for Tim to thaw later.
-------------------------------------------------------
Date: 2000-Jul-09 15:45
By: twouters
Comment:
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 ?
-------------------------------------------------------
Date: 2000-Jul-24 06:15
By: montanaro
Comment:
This new patch is simply an update to keep up with the recent ANSIfication of the Python source...
-------------------------------------------------------
Date: 2000-Jul-27 13:08
By: gvanrossum
Comment:
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.
-------------------------------------------------------
Date: 2000-Jul-27 13:29
By: montanaro
Comment:
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... ***
-------------------------------------------------------
Date: 2000-Jul-28 00:12
By: ping
Comment:
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. :)
-------------------------------------------------------
Date: 2000-Aug-09 06:17
By: montanaro
Comment:
(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)]
-------------------------------------------------------
Date: 2000-Aug-11 18:35
By: gvanrossum
Comment:
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...
-------------------------------------------------------
Date: 2000-Aug-12 02:37
By: twouters
Comment:
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.
-------------------------------------------------------
Date: 2000-Aug-12 10:49
By: montanaro
Comment:
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.
-------------------------------------------------------
Date: 2000-Aug-12 12:23
By: none
Comment:
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?
-------------------------------------------------------
Date: 2000-Aug-14 07:50
By: montanaro
Comment:
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).
-------------------------------------------------------
-------------------------------------------------------
For more info, visit:
http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470