On Sat, 09 Feb 2008 00:04:26 +0000, Matt Nordhoff wrote: > At worst, in and has_key are "about the same".
Except that using has_key() means making an attribute lookup, which takes time. I'm kinda curious why you say they're "about the same" when your own timing results contradict that. Here they are again, exactly as you posted them: $ python -m timeit -s "d = dict.fromkeys(xrange(5))" "4 in d" 1000000 loops, best of 3: 0.233 usec per loop $ python -m timeit -s "d = dict.fromkeys(xrange(5))" "d.has_key(4)" 1000000 loops, best of 3: 0.321 usec per loop For a small dict, a successful search using in is about 1.3 times faster than using has_key(). $ python -m timeit -s "d = dict.fromkeys(xrange(500000))" "499999 in d" 1000000 loops, best of 3: 0.253 usec per loop $ python -m timeit -s "d = dict.fromkeys(xrange(500000))" "d.has_key(499999)" 1000000 loops, best of 3: 0.391 usec per loop For a large dict, a successful search using in is about 1.5 times faster than using has_key(). $ python -m timeit -s "d = dict.fromkeys(xrange(500000))" "1000000 in d" 1000000 loops, best of 3: 0.208 usec per loop $ python -m timeit -s "d = dict.fromkeys(xrange(500000))" "d.has_key(1000000)" 1000000 loops, best of 3: 0.324 usec per loop For a large dict, an unsuccessful search using in is also about 1.5 times faster than using has_key(). Or, to put it another way, has_key() takes about 40-60% longer than in. Now, if you want to argue that the difference between 0.3 microseconds and 0.2 microseconds is insignificant, I'd agree with you -- for a single lookup. But if you have a loop where you're doing large numbers of lookups, using in will be a significant optimization. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
