On Fri, May 08, 2020 at 07:24:43PM -0400, David Mertz wrote: > On Fri, May 8, 2020, 6:39 PM Steven D'Aprano > > > 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. > > > > The OP, with a certain degree of support from you, is asking for changing > the meaning of an operator to enshrine one particular equivalence relation > as syntactically blessed by the language.
https://mail.python.org/archives/list/python-ideas@python.org/message/IRIOEXRYRZYYRHLUYGUOGHZJO6NZBEJD/ Ahmed is no longer asking for any change to the `==` operator. That's multiple dozens of emails out of date. > I note that that equivalence relation is not more important than numerous > other equivalence relations "More important" according to whose needs? I would agree with you that a string method to do case insensitive comparisons would be very useful. I would certainly use that instead of a.casefold() == b.casefold() especially if there was an opportunity to make it more efficient and avoid copying of two potentially very large strings. But why is that relevant? There is no conflict or competition between a new string method and new operator. We could have both! "Case insensitive string comparisons would be useful" is an argument for case insensitive string comparisons, it's not an argument against an unrelated proposal. > and hence should simply be a function > returning a Boolean answer. Sure, we can always write a function. But for something as fundamental as a type of equality, there is much to be said for an operator. That's why we have operators in the first place, including `==` itself, rather than using the functions from the operator module. > I'm certain you understand this, I'm not sure why the facade otherwise. Façade, "a showy misrepresentation intended to conceal something unpleasant" (WordNet). Synonyms include deception, fakery, false front, fraud, imposture, insincerity, simulacrum, subterfuge, and trick. I'm sorry to hear that you are *certain* of my state of mind, and even sorrier that you believe I am lying, but I assure you, I truly do believe that these other equivalence relations are not relevant. And here is why: (1) They require a specialised equivalence relation apart from `==`. Such as math.isclose(), a case insensitive comparison, a JSON comparison. (2) As such they ought to go into their specialist namespaces: - case-insensitive string comparisons should be a string method, or at worst, a function in the string module; - a JSON-comparison probably should go into the json module; - fuzzy numeric equality should probably go into the math module (and that's precisely where isclose() currently exists). And hence they are not in competition with this proposal. (3) Whereas the proposed duck-typing sequence equality relies on the ordinary meaning of equality, applied element by element, ignoring the type of the containers. We can think of this as precisely the same as list equality, or tuple equality, minus the initial typecheck that both operands are lists. If you can understand list equality, you can understand this. You don't have to ask "what counts as close enough? what's JSON?" etc. It's just the regular sequence equality but with ducktyping on containers. It's competely general in a way that the other equivalences aren't. If you think that these other proposals are worth having, and are more useful, then *make the proposal* and see if you get interest from other people. You said that you would prefer to have a JSON-comparing comparison operator. If you use a lot of JSON, I guess that might be useful. Okay, make the case for that to be an operator! I'm listening. I might be convinced. You might get that operator in 3.10, and Python will be a better language. Just start a new, competing, proposal for it. But if you're not prepared to make that case, then don't use the existence of something you have no intention of ever asking for as a reason to deny something which others do want. "Python doesn't have this hammer, therefore you shouldn't get this screwdriver" is a non-sequitor and a lousy argument. > If > you think that yes, that has_same_items() really is that much more > important, present the case for that rather than irrelevant pedantics. That's what I'm trying to do. > But '==' does not guarantee either symmetry or transitivity either. Not > even among objects that intense to mean it in more-or-less the ordinary > sense. Is this intended as an argument for or against this proposal, or is it another "irrelevant pedantics" you just accused me of making? In any case, it is an exaggerated position to take. Among ints, or strings, or floats excluding NANs, `==` holds with all the usual properties we expect: * x == x for all ints, strings and floats excluding NANs; * if, and only if, x == y, then y == x; * and if x == y and y == z, then x == z. It's only Python equality is the *general* sense where the operands could be any arbitrary object that those properties do not necessarily hold. Since this proposal is for a simple duck-typed sequence version of ordinary Python equality, the same generalisation will apply: * If the sequences hold arbitrary objects, we cannot necessarily make any claims about the properties of sequence-equality; * But if you can guarantee that all of the objects are such that the usual properties apply to the `==` operator, then you can say the same about sequence-equality. In this regard, it is exactly the same as list or tuple equality, except it duck-types the container types. -- 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/EGWOKK5BEWNLBET54GNZLOPSMYNH4BO6/ Code of Conduct: http://python.org/psf/codeofconduct/
