From: kj on
In <pan.2010.03.23.01.30.37(a)REMOVE.THIS.cybersource.com.au> Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> writes:

>On Mon, 22 Mar 2010 22:19:57 +0000, kj wrote:

>In any case, the once-off cost of creating or importing a function is
>usually quite cheap. As usual, the best advise is not to worry about
>optimization until you have profiled the code and learned where the
>actual bottlenecks are. Write what reads best, not what you guess might
>be faster, until you really know you need the speed and that it is an
>optimization and not a pessimation.


My preference for map in this case is not due to performance
considerations, but to avoid unnecessary code-clutter. I just
find, e.g.,

x = map(int, y)

slightly easier on the eyes than

x = [int(z) for z in y]

This tiny improvement in readability gets negated if one needs to
define a function in order to use map. Hence, e.g., I prefer

x = [_[0] for _ in y]

over

x = map(lambda _: _[0], y)

and certainly over

def _first(seq):
return seq[0]
x = map(_first, y)

Arguably, Knuth's "premature optimization is the root of all evil"
applies even to readability (e.g. "what's the point of making code
optimally readable if one is going to change it completely next
day?") If there were the equivalent of a profiler for code clutter,
I guess I could relax my readability standards a bit...

~K
From: Jean-Michel Pichavant on
kj wrote:
> Arguably, Knuth's "premature optimization is the root of all evil"
> applies even to readability (e.g. "what's the point of making code
> optimally readable if one is going to change it completely next
> day?")
The guy who will change it will have to read it. The only waste would be
if the code would never be read again.
> If there were the equivalent of a profiler for code clutter,
> I guess I could relax my readability standards a bit...
>
> ~K
>
Don't relax, just keep up :o)

JM