[Python-ideas] Minimal built-ins (+ tiny doc suggestion)

[Guido van Rossum]

On Fri, May 25, 2012 at 9:29 AM, Mike Meyer <mwm at mired.org> wrote:
> On Fri, 25 May 2012 18:28:28 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Fri, May 25, 2012 at 5:53 PM, Mark Summerfield <list at qtrac.plus.com> wrote:
>> > In an effort to keep the core language as small as possible (to keep it
>> > "brain sized":-) would it be reasonable to deprecate filter() and map()
>> > and to move them to the standard library as happened with reduce()?
>> > After all, don't people mostly use list comprehensions and generator
>> > expressions for these nowadays?
>
> Wasn't this changed discussed for that very reason as part of the move
> to 3.x?
>
> Which makes me wonder why reduce moved but not map and filter, when
> map and filter have obvious rewrites as list comprehensions, but
> reduce doesn't? Seems backwards to me.

How quickly we forget.

The point wasn't sparsity of constructs. The point was readability.
Code written using map() or filter(), is usually quite readable --
excesses are possible, but not more so than using list comprehensions.
However code that uses reduce() has a high likelihood of being
unreadable, and is almost always rewritten more easily using a
traditional for loop and some variables that are updated in the loop.

>> The basic problem is that the answer to your question is "no" - for
>> preexisting functions, a lot of people still use filter() and map(),
>> with the comprehension forms reigning supreme only when someone would
>> have had to otherwise use a lambda expression.
>
> Personally, I tend to favor list comprehensions most of the time (and
> I was a pretty heavy user of map and filter in the day), because it's
> just one less idiom to deal with. The exception is when they'd nest -
> I use [map(f, l) for l in list-of-lists] rather than nesting the
> comprehensions, because I then don't have to worry about untangling
> the nest.

There are interesting considerations of readability either way. If you
have to write a lambda to use map() or filter(), it is *always* better
to use a list comprehension, because of the overhead in creating the
stack frame for the lambda. But if you are mapping or filtering using
an already-existing function, map()/filter() is more concise and I
usually find it more readable, because you don't have to invent a loop
control variable. My claim is that for the human reader (who is
familiar with map/filter), it is less work for the brain to understand
map(f, xs) than [f(x) for x in xs] -- there are more words to parse in
the latter, and you have to check that it is the same 'x' in both
places. The advantage of map/filter increases when f is a built-in
function, since the loop implied by map/filter executes more quickly
than the explicit loop (implemented using standard looping byte codes)
used by list comprehensions.

(I hesitate to emphasize the performance too much, since some
hypothetical future Python implementation could make the performance
the same in all cases. But with today's CPython, Jython and
IronPython, it is important to know about relative performance of
different constructs; and even PyPy doesn't alter the equation too
much here. Still, the readability arguments aligns pretty much with
the performance arguments, so they just strengthen each other.)

> But I do agree that since they survived into 3.x, they need to stay
> put until 4.x.

And beyond.

-- 
--Guido van Rossum (python.org/~guido)