dict view values() objects are missing tp_richcmp and tp_as_sequence, and the tests for those were incomplete, which means that on 2.7 and 3.2 (and on current head) viewvalues / values objects don't compare correctly. Without indication, I assume this is not the desired behavior.

Looks like the cause is that the dictview_richcompare function was written to expect a set-like object, and nothing was written for values. I've modified it to accept any view object and do the appropriate check.

One thing I'm unsure of, which I'm sure one of you will help with, is what the desired behavior is on what values() view objects actually *should* be equal to. Being that there isn't a multiset object, and that I couldn't find any resource, I assumed that they only should be equal to other values() objects, not any of the other (ordered) containers. If that's incorrect, or if I need to discuss that on the mailing list, please let me know.

A patch to fix both is attached with the correction to the unit test, hope I did this correctly. I assume this needs to be backported to 2.7, but I figured I'd ask about that first. (Test suite runs without errors on current 3.3 head with this patch for me).

dictview_richcompare also needs unit tests for the NotImplemented error that it should return, but I didn't want to convolute this patch, please let me know if I should put that in here, or file another ticket, or neither.

Thanks!

Looking over this again with a clear head, adding the number operators is the incorrect thing to do here I think, since that function was also written assuming we had a set-like view object as input.

I am inclined to think that the correct behavior here for those operators is to not change that function, but to not make values objects add-able at all, even with other values objects, which would probably be the only other logical choice,  so leaving that as it was before (but still making the equality change).

There is no reasonable semantics for values view.
Keep it unimplemented.

Well, surely there are reasonable semantics :), because dict.values ==
dict.values was comparable before we had view objects.

It's been awhile since I filed this, and still seems rather silly that:

>>>> {"a": "foo"}.values() != {"a": "foo"}.values()
True

On Thu, Mar 28, 2019 at 9:18 AM Inada Naoki <report@bugs.python.org> wrote:

>
> Inada Naoki <songofacandy@gmail.com> added the comment:
>
> There is no reasonable semantics for values view.
> Keep it unimplemented.
>
> ----------
> nosy: +inada.naoki
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue12445>
> _______________________________________
>

> Well, surely there are reasonable semantics :), because dict.values ==
> dict.values was comparable before we had view objects.

Because it was list.

Now values view is not sequence-like or set-like.

>>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
True if set-like.  False if sequence-like.

If you want Python 2 behavior, you should convert it to list.
Then you can use "sequence" semantics.

Yes I know *why* it worked in Py2 -- still seems like an oversight :)

To me, comparing (multi)set-like is the only reasonable behavior there
which is what IIRC the patch did, but even without that, for a given dict,
d.values() != d.values().

So, it's not like comparison is currently unimplemented. It returns
answers, they just mostly make no sense. (And of course I know that what's
happening is we're falling back to an identity check)

On Thu, Mar 28, 2019, 09:51 Inada Naoki <report@bugs.python.org> wrote:

>
> Inada Naoki <songofacandy@gmail.com> added the comment:
>
> > Well, surely there are reasonable semantics :), because dict.values ==
> > dict.values was comparable before we had view objects.
>
> Because it was list.
>
> Now values view is not sequence-like or set-like.
>
> >>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
> True if set-like.  False if sequence-like.
>
> If you want Python 2 behavior, you should convert it to list.
> Then you can use "sequence" semantics.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue12445>
> _______________________________________
>

I don't think we need it.  So I reject it.

If you believe many Pythonista really need it,
please start discussion on python-dev.