On Fri, Dec 18, 2015 at 5:03 PM, Sven R. Kunze srkunze@mail.de wrote:
On 18.12.2015 20:58, Andrew Barnert via Python-ideas wrote:
If you're thinking we could define what multisets should do, despite not having a standard multiset type or an ABC for them, and apply that to values views, the next question is how to do that in better than quadratic time for non-hashable values. (And you can't assume ordering here, either.) Would having a values view hang for 30 seconds and then come back with the answer you intuitively wanted instead of giving the wrong answer in 20 millis be an improvement? (Either way, you're going to learn the same lesson: don't compare values views. I'd rather learn that in 20 millis.)
I like the multiset/bag idea.
Python calls them Counter, right?
Best, Sven
Counter would require hashable values. Any efficient multibag concept, in fact, would. Quadratic multibag comparisons would run into trouble with custom equality.
# Pretending that kwargs is ordered. a0 = dict(x=0, y=1) a1 = a0 b0 = OrderedDict(x=0, y=1) b1 = OrderedDict(y=1, x=0)
d0 = {'foo': a0, 'bar': b0} d1 = {'foo': b1, 'bar': a1}
If we compare a0 == a1 and b0 == b1, then it fails. If we compare a0 == b1 and b0 == a1, then it passes. The order of comparisons matter.
I see two options: - comparison is explicitly NotImplemented. Any code that used it should've used `is`. - comparison respects keys.
OrderedDict values() comparison makes some sense, but its options would be - comparison is sequential. - comparison respects keys.