IIRC, most people agreed on that iterables in the generator expression need to be pre-computed (including myself). But there's a recent issue about that. First, if we precompute iterables in the generator expression, the behavior of it inevitably becomes different from generator expression. For instance, compare followings. >>> list((x,y) for x in iter('abcd') for y in iter('abcd')) [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd')] >>> [(x,y) for x in iter('abcd') for y in iter('abcd')] [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b', 'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'), ('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')] c.f) >>> a = iter("abcd"); b = iter("abcd"); [(x,y) for x in a for y in b] [('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd')] Also, like arigo commented in the sf patch, the things we are looping over may depend on other stuff from the generator expression itself. >>> [x for l in [[1,2],[3,4]] for x in l] [1, 2, 3, 4] >>> (y for m in [[1,2],[3,4]] for y in m) NameError: name 'm' is not defined More comments are in sf, http://sourceforge.net/tracker/?func=detail&aid=872326&group_id=5470&atid=305470 Comments after 2004-03-19 22:37 (posted by quiver) are about that issue. Do we need to drop precomputation of iterables? Regards, Jiwon.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4