On Thu, 7 May 2020 19:11:43 +1000
Steven D'Aprano
We could define this .EQ. operate as *sequence equality*, defined very roughly as:
def .EQ. (a, b): return len(a) == len(b) and all(x==y for x, y in zip(a, b))
Equality and its awkward cousin equivalence are slippery slopes. Just sequences? That (admittedly rough) function returns true for certain mapping arguments. What about case-insensitive string matching? Is that more common than comparing (or wanting to compare) arbitrary sequences? What about an operator for normalized (in the Unicode sense of the word), case-insensitive string comparison? (There's a precedent: Common Lisp's equalp function does case-insensitive string matching.) The strongest equality is the "is" operator, and then the == operator, and ISTM that you're now extending this idea to another class of equivalency. The very far ends of that scale are glossing over American vs. British spellings (are "color" and "colour" in some sense equal?), or even considering two functions "the same" if they produce the same outputs for the same inputs. One of Python's premises and strengths is strong typing; please don't start pecking away at that. Do beginners expect that [1, 2, 3] == (1, 2, 3)? No. Do experts expect that [1, 2, 3] == (1, 2, 3)? No. So who does? Programmers working on certain applications, or with multiple [pre-existing] libraries, or without a coherent design. These all seem like appliction level (or even design level) problems, or maybe a series of dunder methods / protocols to define various levels of equivalence (the ability of my inbox and my brain to handle the resulting bikeshedding notwithstanding). YMMV. Just my thoughts. -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan