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/
