classification
Title: dict view values objects are missing tp_richcmp and tp_as_number
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Julian, ezio.melotti, methane, rhettinger
Priority: normal Keywords: patch

Created on 2011-06-30 00:03 by Julian, last changed 2019-03-28 14:01 by methane. This issue is now closed.

Files
File name Uploaded Description Edit
viewvalues_compare.patch Julian, 2011-06-30 00:03 review
Messages (7)
msg139455 - (view) Author: Julian Berman (Julian) * Date: 2011-06-30 00:03
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!
msg139484 - (view) Author: Julian Berman (Julian) * Date: 2011-06-30 15:00
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).
msg339032 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2019-03-28 13:18
There is no reasonable semantics for values view.
Keep it unimplemented.
msg339040 - (view) Author: Julian Berman (Julian) * Date: 2019-03-28 13:45
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>
> _______________________________________
>
msg339041 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2019-03-28 13:51
> 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.
msg339044 - (view) Author: Julian Berman (Julian) * Date: 2019-03-28 13:56
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>
> _______________________________________
>
msg339045 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2019-03-28 14:01
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.
History
Date User Action Args
2019-07-13 12:49:40serhiy.storchakalinkissue37585 superseder
2019-06-01 06:08:29serhiy.storchakalinkissue37119 superseder
2019-03-28 14:01:36methanesetmessages: + msg339045
2019-03-28 13:56:13Juliansetmessages: + msg339044
2019-03-28 13:51:17methanesetmessages: + msg339041
2019-03-28 13:45:51Juliansetmessages: + msg339040
2019-03-28 13:18:22methanesetstatus: open -> closed

nosy: + methane
messages: + msg339032

resolution: rejected
stage: patch review -> resolved
2011-06-30 15:00:10Juliansetmessages: + msg139484
2011-06-30 00:09:56ezio.melottisetnosy: + rhettinger, ezio.melotti

stage: patch review
2011-06-30 00:03:10Juliancreate