There's a few good reasons. 1 - golden handcuffs. Breaking old code is bad 90% of the time 2 - creating a set MAY be slower.
Python's sets seem to imply to that they will always be a hash map. in this case, some creative hash map "mapping" could allow one to create a set without calculating hash codes (make the set hashmap have the same dimentions and rules as the dictionary one). If there was intent to allow Python implementations to use trees for the set, then a list is far faster to create (O(n) time instead of O(nlogn)). 3 - using a set is sometimes slower (just as using a list is sometimes slower) I can't speak for your code, but this is the most common use of keys in my coding: # d is some dictionary keys = d.keys() keys.sort() for k in keys: #blah sets cannot be sorted, while lists can. If keys() returned a set, then I'd have to turn it into a list every time. There's potential to add "views" to python (a key view of a dictionary being a frozenset containing the dictionary's keys, which is updated whenever the dictionary updates), but I think thats annother topic which is out of the scope of your origional idea. -- http://mail.python.org/mailman/listinfo/python-list
