"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
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