Thomas Wouters wrote: > > ... > > Well, not really. It doesn't create a new list, only a tuple to hold lists > to iter over (in order to pass it to the opcode as a single PyObject) and > similar for the resulting objects. It's definately more efficient than the > map() solution (and different, see below ;) Nevertheless, I think it is worth asking whether a parallel() or merge() function can do the same thing. It's not like the semicolon syntax screams out the right answer. The parallel function could return an iteratable object that generates tuples on demand. A function can be used in contexts other than a for loop. If we make functions like parallel and range not only builtin but non-overridable, we can do all sorts of optimizations in the bytecode compiler (and other compilers). In other words we can "inline" them when they are used in simple contexts. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html
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