On Fri, May 08, 2020 at 01:26:05PM -0400, David Mertz wrote: > The distinction you make seems both pedantic and factually wrong.
Which distinction are you referring to? The one between `is` and `==`? And in what way is it factually wrong? > More flat-footed still is "equal objects are ones whose .__eq__() > method returns something truthy." Nevertheless, flat-footed or not, that is broadly the only meaning of equality that has any meaning in Python. Two objects are equal if, and only if, the `==` operator returns true when comparing them. That's what equality means in Python! (There are a few nuances and complexities to that when it comes to containers, which may short-cut equality tests with identity tests for speed.) > It doesn't actually need to define any of the behaviors we think of as > equality/equivalence. Indeed. Which is why we cannot require any of those behaviours for the concept of equality in Python. > Both '==' and 'is' are ways of saying equivalent-for-a-purpose. `==` is the way to say "equal", where equal means whatever the class wants it to mean. If you want to describe that as "equivalent-for-a- purpose", okay. But `is` compares exactly and only "object identity", just as the docs say, just as the implementation, um, implements. That's not an equivalence, at least not in the plain English sense of the word, because an equivalence implies at least the possibility of *distinct* objects being equivalent: a is equivalent to b but a is not identical to b Otherwise why use the term "equivalent" when you actually mean "is the same object"? By definition you cannot have: a is identical to b but a is not identical to b so in this sense `is` is not a form of equivalence, it is just *is*. The mathematical sense of an equivalence relation is different: object identity certainly is an equivalence relation. [...] > Given that different Python > implementations will give different answers for 'some_int is > some_other_int' where they are "equal" in an ordinary sense, identity isn't > anything that special in most cases. Right. Remind me -- why are we talking about identity? Is it relevant to the proposal for a duck-typing container equals operator? [...] > The only cases where identity REALLY has semantics I would want to rely on > are singletons like None and True, and I guess for custom mutable objects > when you want to make sure which state is separated versus shared. Well, > OK, I guess lists are an example of that already for the same reason. So... only None, and True and False, and other singletons like NotImplemented, and custom mutable objects, and builtin mutable objects like list and dict and set, and typically for classes, functions and modules unless you're doing something weird. Okay. > For non-singleton immutables, identity is not really a meaningful thing. It's of little practical use except to satisfy the caller's curiousity about implementation details. -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CSJF2BHBES4VURVPTNMRQB74ZRDSL4MB/ Code of Conduct: http://python.org/psf/codeofconduct/