short-circuiting any/all ?

[kj]

In <pan.2010.03.23.01.30.37 at REMOVE.THIS.cybersource.com.au> Steven D'Aprano <steven at 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