What is the more pythonic way of getting the length of the longest word:
len(max(words, key=len))
Or:
max(len(w) for w in words)
Or.. something else? words
is a list of strings.
I am finding I need to do this often and after timing with a few different sample sizes the first way seems to be consistently faster, despite seeming less efficient at face value (the redundancy of len
being called twice seems not to matter - does more happen in C code in this form?).
If you rewrite the generator expression as a
map
call (or, for 2.x,imap
):… it's actually a bit faster than the key version, not slower.
python.org 64-bit 3.3.0:
Apple 64-bit 2.7.2:
I think it's more pythonic than the
key
version, for the same reason the genexp is.It's arguable whether it's as pythonic as the genexp version. Some people love
map
/filter
/reduce
/etc.; some hate them; my personal feeling is that when you're trying to map a function that already exists and has a nice name (that is, something you don't have tolambda
orpartial
up),map
is nicer, but YMMV (especially if your name is Guido).One last point:
Think about it like this: You're already calling
len
N times. Calling itN+1
times instead is hardly likely to make a difference, compared to anything you have to doN
times, unless you have a tiny number of huge strings.Although:
does kind of "read" easier - you've got the overhead of a generator.
While:
can optimise away with the key using builtins and since
len
is normally a very efficient op for strings, is going to be faster...I think both are OK, but I think that unless speed is a big consideration that
max(len(w) for w in words)
is the most readable.When I was looking at them, it took me longer to figure out what
len(max(words, key=len))
was doing, and I was still wrong until I thought about it more. Code should be immediately obvious unless there's a good reason for it not to be.It's clear from the other posts (and my own tests) that the less readable one is faster. But it's not like either of them are dog slow. And unless the code is on a critical path it's not worth worrying about.
Ultimately, I think more readable is more Pythonic.
As an aside, this one of the few cases in which Python 2 is notably faster than Python 3 for the same task.
I know it's been a year now but neverthless, I came up with this:
'''Write a function find_longest_word() that takes a list of words and returns the length of the longest one.'''
Just for info using
ipython %timeit
Just updated with more words to demonstrate @Omnifarious's point/comment.
I'd say
looks quite good because you utilize a keyword argument (
key
) of a built-in (max
) with a built-in (len
). So basicallymax(x, key=len)
gets you almost the answer. But none of your code variants look particularly un-pythonic to me.