On Thu, 7 May 2020 at 02:07, David Mertz <me...@gnosis.cx> wrote: > > That's the point though. For *most* functions, the substitution principle is > fine in Python. A whole lot of the time, numeric functions can take either > an int or a float that are equal to each other and produce results that are > equal to each other. Yes, I can write something that will sometimes overflow > for floats but not ints. Yes, I can write something where a rounding error > will pop up differently between the types. But generally, numeric functions > are "mostly the same most of the time" with float vs. int arguments.
The question is whether you (or Chris) care about calculating things accurately with floats or ints. If you do try to write careful code that calculates things for one or the other you'll realise that there is no way to duck-type anything nontrivial because the algorithms for exact vs inexact or bounded vs unbounded arithmetic are very different (e.g. sum vs fsum). If you are not so concerned about that then you might say that 1 and 1.0 are "acceptably interchangeable". Please understand though that I am not proposing that 1==1.0 should be changed. It is supposed to be a simple example of the knock on effect of defining __eq__ between non-equivalent objects. > This doesn't say whether tuple is as similar to list as frozenset is to set. > But the answer to that isn't going to be answered by examples constructed to > deliberately obtain (non-)substitutability for the sake of argument. Those examples are not for the sake of argument: they are simple illustrations. I have fixed enough real examples of bugs relating to this to come to the conclusion that making non-interchangeable objects compare equal with == is an attractive nuisance. It seems useful when you play with toy examples in the REPL but isn't actually helpful when you try to write any serious code. This comes up particularly often in sympy because: 1. Many contributors strongly feel that A == B should "do the right thing" (confusing structural and mathematical equality) 2. Many calculations in sympy are cached and the cache can swap A and B if A == B. 3. There are a lot of algorithms that make heavy use of ==. The issues are the same elsewhere though: gratuitously making objects compare equal with == is a bad idea unless you are happy to substitute one for the other. Otherwise what is the purpose of having them compare equal in the first place? Oscar _______________________________________________ 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/ZB7EIJJ7LG2LGR73EV3LGPURLWJD677Z/ Code of Conduct: http://python.org/psf/codeofconduct/
