"Barry A. Warsaw" wrote:
I've made a final pass through PEP 201, Parallel Iteration. For those of you without easy access to the CVS tree, I'm including it below. You can also access it through the web at
Great work. It's a pleasure to read.
High bit: Guido strongly prefers zip() as the name of the built-in. All the suggestions so far have pluses and minuses, and in the absence of a clear winner, he'd just as soon go with the Haskell name. I agree.
I agree (giving +1 would be blasphemy, right?<wink>). One important remark: What about unzip()? Shouldn't there be the reverse function? One example (which I really wrote not so long ago in an ANN context): def normalize(seq): # scale to values in 0..1 return map(lambda x, max=max(seq), min=min(seq): (x-min)/(max-min), seq) # from file with: x1 y1 z1\nx2 y2 z2\n etc. data = [[1.0, 2.0, 3.0], [-1.0, 1.0, -1.0], [-1.0, -2.0, -3.0], [2.0, 3.0, 1.0]] # zip related data fields, normalize that field, unzip data = unzip(map(normalize,zip(data)))
Please see the new reference implementation, which includes a __len__() method, and the discussion of the rejected elaborations. There's still the open issue of what zip(sequence_a) should return.
I think zip([1, 2, 3]) should give ((1), (2), (3)). My reasons? 1) It feels right to me. 2) It is the way Lisp (or Scheme, don't remember) deals with it. [Haskell's zip-unzip is limited to two lists] By the way, yet another example for unzip(): mylist = [(1,), (2,), (3,)] What looks better? a) newlist = map(lambda x:x[0], mylist) b) newlist = unzip(mylist) advocating-unzip-as-an-overridable-builtin-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de