Martin Häcker added the comment: Sorry, I got the title wrong on the first try. (Already corrected).
I think the problem is that the API of dict.keys() is surprising. One gets back something that behaves like a list, the name 'keys' suggests that it is a list and for lists there is no requirement that their containing items need to be hasheable. Now of course it makes no sense to check if a dict (not washable because it's mutable) is a key in a dictionary - but, the fact that keys() returns something else than a list is surprising and shouldn't be so. (I suspect it's a performance enhancement). Why this shouldn't be so? I think it's because of composeability. If I expect something list like from an API I want to be able to hand it around in my application to everywhere where a list is allowed, and I certainly don't want to check beforehand if something I want to check is included in that list is hasheable for a specific subset of those lists. Thats why I think it's a really bad idea to change the behavior of dict.keys() _not_ to return a list or something that at least behaves the same way as a list. Should this have been done for performance reasons, it would be easy to say in that list that anything that is not hasheable cannot be in that list and therefore to return False in that case. Contract fulfilled. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20190> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
