On Thu, 7 May 2020 at 08:54, Greg Ewing
On 7/05/20 1:07 pm, David Mertz wrote:
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.
It's not much use for deciding whether two things *should* be equal, though, because whatever your opinion on the matter, you can come up with a set of functions that satisfy it and then say "those are the kinds of functions I mean".
Also, as a definition of equality it seems somewhat circular, since if you're not sure whether x == y, you may be equally uncertain whether f(x) == f(y) for some f, x, y.
It's not so much a definition of equality as a consistency requirement. The contrapositive can be very clear: if you already know that f(x) and f(y) do different things or return unequal objects then the question of whether x == y is answered. It's important though that it's not just about equality of return types: when you carry the principle over from maths to programming then you need to consider non-pure functions, IO, exceptions being raised etc. In simple situations it is nice to be able to duck-type over lists and tuples but in practice it has to be done carefully by sticking to the sequence or iterable interfaces precisely or by coercing to a known type at the entry points of your code. Once you have a large codebase with lots of objects flying around internally and you no longer know whether anything is a list or a tuple (or a set...) any more it's just a mess. Oscar