my favorite line of py code so far

[Peter Otten]

Peter Cacioppi wrote:

> Peter Otten said:
> 
> 
> ">>> _ = lambda c: lambda x: c(*x)
>>>> list(map(_(P), zip([1,2,3], [6, 5, 4])))
> [Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)]
> 
> ? While the obvious approach would be
> 
>>>> [P(*args) for args in zip([1,2,3], [6, 5, 4])]
> [Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)] "
> 
> I would have coded
>>>> map(_(P), zip([1,2,3], [6, 5, 4]))
> 
> Which is very concise and (to me) quite clear. Forgive me for having a
> bias for fewer characters.

Consider developing a bias for self-explanatory names ;)

> Are you saying it's always preferable to avoid map? 

No. I'm saying that if you have a problem with multiple solutions you should 
pick the boringly obvious one if you plan to reuse or publish the code.

There is no obvious meaning attached to _ -- so don't use it.

> Is map going to be deprecated?

Not to my knowledge. I use it when I already have a function ready 
to be called with the items in a sequence. Continuing the Point example that 
could be

map(Point, xvals, yvals)

or

map(Point.from_tuple, xypairs)

> I sometimes use map, sometimes comprehensions. I suspect other people do
> the same, that's why the language supports map and comprehensions.
> 
> "there is also itertools.starmap(): "
> 
> Thanks, that's a bit closer to what I am doing.  To me the pure combinator
> is more appealing than starmap, but the presence of starmap explains why
> the library wouldn't need the combinator.

I found only a single use of starmap on my machine (and one more in the 
stdlib)

# in redis.client
all_cmds = ''.join(starmap(connection.pack_command,
                           [args for args, options in commands]))

and frankly, I would prefer

all_cmds = "".join(
    connection.pack_command(*args) for args, options in commands)

which by some strange coincidence also requires fewer letters to type.