I was too; I think the connection Steve saw is that they're all
traditional in lispish languages but not in others. Agreed that map/
filter/reduce are easy to write in Python (although, as you pointed out
later, it's a puzzle to write map(f,many_lists) _efficiently_ in Python).
> ...
> and lambda can be replaced either by something using eval() or by
> using 'def'.
Indeed, quite a while back I posted a 'lambda' function written in
Python. I still like the builtin a lot better, cuz passing a string was
artificial. WRT the 'def' alternative, I used that too, but in
interactive use it was a real problem to remember the _names_ of all the
goofy little one-line def's I wrote as a session went along. It's just
easier/faster/less-error-prone to type the lambda directly at the point
of use.
The built-in lambda isn't a big deal! It's a nice convenience. At least
if people let it _stay_ simple, I don't think you should regret it.
> > for thing in everything:
> > if uninteresting(thing): continue
> >
> > isn't really obnoxious. So how come it irritates us?! I haven't figured
> > that out yet.
>
> Doesn't irritate me at all. In fact this is a style I use all the
> time.
Ya, the "us" there was Steve & me. I don't often go to the extreme of
replacing the whole thing with a map/filter composition, but will do
"for thing in filter(interesting, everything)" when "interesting" has
already been written as a function with a mnemonic name. These are just
style preferences, Guido -- loathe though I am to admit that my
preferences may not be expressions of Absolute Truth <grin>.
> [other good points omitted, just cuz i have nothing to add]
> > > [ (a,x), (b,y), (c,z) ] = [ a, b, c ] "some-operator" [ x, y, x ]
> I'm not against such an operator, though I suggest that (since it
> would apply to more than two arguments as well and might have mixed
> argument types) it should be a function and not a method. Funnily
> enough, without resorting to map(None, ...), it is remarkably hard to
> write in Python:
See? Having "map" as a built-in _is_ useful <wink>.
> def zip(*args):
> [correct but painful implementation deleted]
> ...
> def tuple(list):
> t = ()
> for i in list: t = t + (i,)
> return t
>
> I might make something like tuple() a built-in in the next release --
> this version is O(N**2), it may be possible to write an O(log N)
Assuming O(N * log N) was intended at the end.
> version in Python, but in C there an O(N) implementation is trivial!
_I_ would like that! E.g., sometimes I build up a list of arguments, and
then do something similar to the above so I can use 'apply'. Why didn't
I build them as a tuple to begin with? Reasons vary; often just a lack
of foresight.
BTW, when the reference count on a list is 1, I suspect you could get an
O(1) tuple implementation by just replacing the type pointer. That has
all sorts of ugly implications, though ...
> On the other hand, what's wrong with returning a list of lists,
> avoiding the need for list->tuple conversion at all?
Perhaps just the syntactic naturalness of being able to write
for x, y in zip(sequence1, sequence2):
instead of
for [x, y] in zip(sequence1, sequence2):
I suspect that's the most common use.
> And last but not least, is "zip" a good name for this function?
zip is a WONDERFUL name, but best understood after urinating <wink>. If
you picture [a,b,c] and [x,y,z] as being the two halves of an open
zipper, [(a,x), (b,y), (c,z)] is what you get after you "zip up". I
don't know whether functional languages will survive long-term, but they
earned their place in history for this name alone!
BTW, I'm happy with the zip one-liner based on map, written in Python.
If you want to make it built-in, maybe it's time to introduce a std
"things you often find in functional languages but rarely find elsewhere"
module and put it there. While zip can be handy, I don't think it's
handy enough for most people most of the time to justify a home in
__builtin__. And if its use in "for" to traverse multiple sequences is
seen as the major benefit, might it be more effective to address that
directly by making "for" smarter?
caught-in-the-zipper-again-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp