Steven D'Aprano wrote: > On Sun, 03 Jul 2005 08:14:28 -0700, Scott David Daniels wrote: > > > egbert wrote: > >> On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote: > >> > >>>Also, map is easily replaced. > >>>map(f1, sequence) == [f1(element) for element in sequence] > >> > >> How do you replace > >> map(f1,sequence1, sequence2) > >> especially if the sequences are of unequal length ? > >> > >> I didn't see it mentioned yet as a candidate for limbo, > >> but the same question goes for: > >> zip(sequence1,sequence2) > > > > OK, you guys are picking on what reduce "cannot" do. > > The first is [f1(*args) for args in itertools.izip(iter1, iter2)] > > And now we get messier and messier... Compare these two idioms: > > "Map function f1 to each pair of items from seq1 and seq2." > > "Build a list comprehension by calling function f1 with the unpacked list > that you get from a list built by zipping seq1 and seq2 together in pairs."
The shamelessness with which you inflated the verbosity of the latter is hilarious. > Good thing that removing reduce is supposed to make code easier to > understand, right? It was a bad example. I would say most people don't usually just call a function in the list comp, because, frankly, they don't have to. A realistic list comp would look something like this in a real program: [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ] Now there's no longer much advantage in conciseness for the map version (seeing that you'd have to define a function to pass to map), and this is more readable. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
