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. -- https://mail.python.org/mailman/listinfo/python-list