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)] How to _you_ use map to avoid making all the intermediate structures? I never saw anything about making zip go away. It is easy to explain. Now reduce maps to what I was taught to call "foldl." How do you express "foldr?" How do you express: _accum = initial() for elem in iterable: _accum = func(elem, _accum, expr) ... If you want functional programming in python, you have at least three big problems: 1) Python has side effect like mad, so order of evaluation matters. I'd claim any useful language is like that (I/O to a printer is kind of hard to do out-of-order), but I'd get sliced to death by a bunch of bullies wielding Occam's razors. 2) Python's essential function call is not a single-argument function which might be a tuple, it is a multi-argument function which is not evaluated in the same way. The natural duality of a function taking pairs to a function taking an arg and returning a function taking an arg and returning a result breaks down in the face of keyword args, and functions that take an indeterminate number of arguments. Also, because of (1), there is a big difference between a function taking no args and its result. 3) Python doesn't have a full set of functional primitives. Fold-right is one example, K-combinator is another, .... Why pick on reduce as-is to keep? There is another slippery slope argument going up the slope adding functional primitives. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list