I agree with Greg.

There are various possible behaviors that might make sense, but having `d.values() != d.values()` is about the only one I can see no sense in.

This really feels like a good cade for reading a descriptive exception. If someone wants too compare `set(d.values())` that's great. If they want `list(d.values())`, also a sensible question. But the programmer should spell it explicitly.

This feels similar to NumPy arrays, that also will not compare for equality in bare form. But they offer .any(), and .all() and other means of expressing the comparison you actually want in a situation.

On Wed, Jul 24, 2019, 6:32 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Steven D'Aprano wrote:
> Currently that assertion fails. Should it? Putting aside the convenience
> of "do nothing, just inherit the object.__eq__ behaviour" do you think
> that the current behaviour is *correct*?

What I'm getting from this thread is that there are a variety of
possible behaviours for dict values comparison, any of which could
be considered "correct" depending on what the programmer is trying
to do.

I know there are good reasons for the guideline that equality
comparisons should never raise exceptions, but this seems like a
situation where Python really should slap you on the ear and
make you specify exactly what you want.

--
Greg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WR2JGENQBL3EQ6ZUUFF2BPMMFTFDEH3R/