Message339044
| 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>
> _______________________________________
> |
|