Is it always faster to use string as key in a dict?
<p>On this <a href="http://wiki.python.org/moin/TimeComplexity" rel="nofollow">page</a>, I see something interesting:</p>

<p><em>Note that there is a fast-path for dicts that (in practice) only deal with str keys; this doesn't affect the algorithmic complexity, but it can significantly affect the constant factors: how quickly a typical program finishes.</em></p>

<p>So what does it exactly mean?</p>

<p>Does it mean using string as the key is always faster?</p>

<p>If yes, why?</p>

<p><strong>Update:</strong></p>

<p>Thanks for the suggestions about optimization! But I'm actually more interested in the plain truth, than whether or when we should do optimization.</p>

<p><strong>Update 2:</strong></p>

<p>Thanks for the great answers, I'll cite the content from the <a href="http://lewk.org/blog/python-dictionary-optimizations" rel="nofollow">link</a> provided by @DaveWebb here:</p>

<p>"
...</p>

<p><strong>ma_lookup</strong> is initially set to the <strong>lookdict_string</strong> function (renamed to <strong>lookdict_unicode</strong> in 3.0), which assumes that both the keys in the dictionary and the key being searched for are standard PyStringObject's. It is then able to make a couple of optimiziations, such as mitigating various error checks, since string-to-string comparison never raise exceptions. There is also no need for rich object comparisons either, which means we avoid calling <strong>PyObject_RichCompareBool</strong>, and always use <strong>_PyString_Eq</strong> directly.</p>

<p>...
"</p>

<p>Also, for the experiment numbers, I think the size of the difference will be even bigger if there is no int-to-string conversion</p>
