map/filter/reduce/lambda opinions and background unscientificmini-survey

[Steven D'Aprano]

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

Good thing that removing reduce is supposed to make code easier to
understand, right?


> How to _you_ use map to avoid making all the intermediate structures?

I don't understand the question. Presumably the sequences already exist.
That's not the point.

> I never saw anything about making zip go away.  It is easy to explain.

I don't find map any less clear than zip.

Except for the arbitrary choice that zip truncates unequal sequences while
map doesn't, zip is completely redundant:

def my_zip(*seqs):
    return map(lambda *t: t, *seqs)

Zip is just a special case of map. I find it disturbing that Guido is
happy to fill Python with special case built-ins like sum, zip and
(proposed) product while wanting to cut out more general purpose solutions.


[snip]
> 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.

Not if you *just* use functional operations.

Not that I would ever do that. The point isn't to turn Python into a
purely functional language, but to give Python developers access to
functional tools for when it is appropriate to use them.

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

And I'm sure that makes a difference to the functional programming
purists. But not to me.

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

My car isn't amphibious, so I can't go everywhere with it. Should I throw
it away just because I can't drive under water?

No, of course not. Just because Python isn't a purely functional language
doesn't mean that we should reject what functional idioms (like list
comps, and zip, and reduce) it does have.

Personally, I'd like to learn more about about fold-right and
K-combinator, rather than dump reduce and map.

Frankly, I find this entire discussion very surreal. Reduce etc *work*,
right now. They have worked for years. If people don't like them, nobody
is forcing them to use them. Python is being pushed into directions which
are *far* harder to understand than map and reduce (currying, decorators,
etc) and people don't complain about those. And yet something as simple
and basic as map is supposed to give them trouble? These are the same
people who clamoured for zip, which is just a special case of map?


-- 
Steven.