dictionary - python dictionries when keys are numbers -

this question has answer here:

• why order in dictionaries , sets arbitrary? 5 answers

i have question dictionary properties in python when keys number. in case when print dictionary number keys result of print sorted keys in other case (keys string) dictionary unordered. want know rule in dictionaries.

l = {"one" : "1", "two" : "2", "three" : "3"}  print(l)  l = {1: "one", 2: "two", 3: "three", 4: "four", 5: "five"}  print(l)  l = {2: "two", 3: "three", 4: "four", 1: "one", 5: "five"}  print(l) 

result:

{'three': '3', 'two': '2', 'one': '1'}  {1: 'one', 2: 'two', 3: 'three', 4: 'four', 5: 'five'}  {1: 'one', 2: 'two', 3: 'three', 4: 'four', 5: 'five'} 

python use hash table storing dictionaries there no ordered in dictionaries or other objects use hash function.

but indices of items in hash object, python calculate indices based on following code within hashtable.c:

key_hash = ht->hash_func(key); index = key_hash & (ht->num_buckets - 1); 

so hash value of integers integer index based on number (ht->num_buckets - 1 constant) index calculated bitwise-and between (ht->num_buckets - 1) , number.

consider following example set use hash-table :

>>> set([0,1919,2000,3,45,33,333,5]) set([0, 33, 3, 5, 45, 333, 2000, 1919]) 

for number 33 have :

33 & (ht->num_buckets - 1) = 1 

that it's :

'0b100001' & '0b111'= '0b1' # 1 index of 33 

note in case (ht->num_buckets - 1) 8-1=7 or 0b111.

and 1919 :

'0b11101111111' & '0b111' = '0b111' # 7 index of 1919 

and 333 :

'0b101001101' & '0b111' = '0b101' # 5 index of 333 

for more details python hash function read following quotes python source code :

major subtleties ahead: hash schemes depend on having "good" hash function, in sense of simulating randomness. python doesn't: important hash functions (for strings , ints) regular in common cases:

>>> map(hash, (0, 1, 2, 3))   [0, 1, 2, 3] >>> map(hash, ("namea", "nameb", "namec", "named"))   [-1658398457, -1658398460, -1658398459, -1658398462] 

this isn't bad! contrary, in table of size 2**i, taking low-order bits initial table index extremely fast, , there no collisions @ dicts indexed contiguous range of ints. same approximately true when keys "consecutive" strings. gives better-than-random behavior in common cases, , that's desirable.

otoh, when collisions occur, tendency fill contiguous slices of hash table makes collision resolution strategy crucial. taking last bits of hash code vulnerable: example, consider list [i << 16 in range(20000)] set of keys. since ints own hash codes, , fits in dict of size 2**15, last 15 bits of every hash code 0: all map same table index.

but catering unusual cases should not slow usual ones, take last bits anyway. it's collision resolution rest. if usually find key we're looking on first try (and, turns out, -- table load factor kept under 2/3, odds solidly in our favor), makes best sense keep initial index computation dirt cheap.