On Fri, May 08, 2020 at 03:16:48PM -0400, David Mertz wrote:
On Fri, May 8, 2020 at 1:47 PM Steven D'Aprano
wrote: All of which are red herrings that are completely off-topic for this proposal. This proposal has nothing to do with:
case_insensitive_eq(a, b) same_json_representation(a, b) allclose(a, b) # A version of this is in NumPy nan_ignoring_equality(a, b)
I think you are trying very hard to miss the point. Yes... all of those functions that express a kind of equivalence are different from the OP proposal. But ALL OF THEM have just as much claim to being called equivalence as the proposal does.
So what? Why is this relevant? This is not a proposal for a generalised equivalence relation. If you want one of those feel free to propose a competing idea. (To be pedantic: at least the allclose() one is not an equivalence relation, as it would be possible to have isclose(a, b) and isclose(b, c) but not isclose(a, c). But that's a by-the-by.) Duck-typed sequence-equality requires no specialised equivalence relation. It's exactly the same as existing notions of container equality, except without the type-check on the container. It is a generic operation, not a specialised one like checking for fuzzy numeric close-enoughness, or JSON representations. If you want case insensitive string equality, propose a new string method.
If we could only extend the '==' operator to include one other comparison, I would not choose the OP's suggestion over those others. Similarly, if '===' or '.EQ.' could only have one meaning, the OP proposal would not be what I would most want.
Great! Start your own proposal in a new thread then and stop hijacking this one. -- Steven