This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Julian
Recipients Julian, ezio.melotti, methane, rhettinger
Date 2019-03-28.13:56:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CABJQSkme0=qL+Mr3-O4gD_Lb4j2CStd_00-BdzGWXVu87KT0hQ@mail.gmail.com>
In-reply-to <CAEfz+TxtqkmK1t1iuz37KK=+v03Md_O6Uf8RdU-kf7bwK0H6qQ@mail.gmail.com>
Content
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>
> _______________________________________
>
History
Date User Action Args
2019-03-28 13:56:13Juliansetrecipients: + rhettinger, ezio.melotti, methane
2019-03-28 13:56:13Julianlinkissue12445 messages
2019-03-28 13:56:13Juliancreate