Jim Baker writes:
We should keep the most heavily accessed object type in Python as lightweight as possible, and then build interesting structures around it, just like we always do.
+1 But we're not talking about the dict itself in this subthread. We're talking about views, and the implementation of comparing items containing non-hashable values for equality will be done in a view method which is already worst-case O(n), not a dict method. Note that the current implementation means that an equality comparison can raise, and that's a very bad thing. If you look at the thread Inada-san cited a couple posts back, you'll see some very strong statements in support of the proposition that == should *never* raise. I find that persuasive. I'm still against the implementation of "values view as sequence", since all the alleged use cases are of the form "maybe you'd want this someday for a really big dict so you don't want to listify so you can sort/index/etc." Show me real code, preferably production (ie, used at work -- might even be a throwaway script) and I'll concede there's an argument. But nothing abstract is gonna move me even one Planck unit from -1. (That's just my opinion, as usual YMMV etc)