Dijkstra on Python

[Christopher A. Craig]

"James J. Besemer" <jb at cascade-sys.com> writes:

> > Still, he admits to the occasional weak moment
> >        (lambda, for example).
> 
> Then he should really be kicking himself over list comprehensions.  ;o)
> 
> I mean this strikes me as crazy.  People are saying get rid of lambda
> and map when they're typically faster than for or while loops and
> then they praise comprehensions when they're the most unusual
> and slowest of all.
> 

Have you ever actually done timing tests?  Lets take something simple
like the example from Guido's optimization paper:

def natural(list):
  output = []
  append = output.append
  for item in list:
    append(chr(item))
  return "".join(output)

def lambda_(list):
  return "".join(map(lambda item: chr(item), list))

def listcomp(list):
  return "".join([ chr(item) for item in list ])


Given 100k random elements natural did this in .49 seconds, lambda in
.58, and listcomps in .48, making listcomps the fastest and lambda the
slowest.  I've done timing tests on lots of loops like this and it's
generally (ordered from fastest to slowest)

map/filter/reduce on a builtin or C function
listcomps 
normal for/while loop 
map/filter/reduce on a lambda function

Before you argue "But you didn't need a lambda there," I know I
didn't.  Mapping on the builtin chr() would have been a lot faster
than listcomps, but your argument was for keeping lambda, not map.
The function call overhead of lambda is almost always worse (maybe
always, I've never seen it better) than a listcomp.  Plus there are
all sorts of language problems with lambda (They can't contain
multiple statements, they didn't used to be able to use variables from
the containing scope...)


-- 
Christopher A. Craig <list-python at ccraig.org>
..the Court's opinion will accomplish the seemingly impossible feat of leaving
this area of the law more confused than it found it.  -- Justice Rehnquist