[Python-ideas] PEP 485: A Function for testing approximate equality

[Paul Moore]

On 27 January 2015 at 04:25, Chris Barker <chris.barker at noaa.gov> wrote:
> But one reason to take it off-list is that these very long, if not endless,
> circular conversations gives the impression that it really matters which
> specif choices are made, and that we will never come to a consensus about
> it, so this should not go in the stdlib.

Hmm. That's a reason for writing a PEP, and getting feedback. If
people feel strongly enough about the colour of the bikeshed to vote
against the PEP, then it matters, otherwise not. If you believe it's
only details by now and people can live with most of the options,
maybe it's time to declare the PEP as complete, and post to python-dev
for final comments before asking for a pronouncement?

> However, I'm pretty sure that we're down to details, that while interesting,
> don't really matter -- whether we use a asymmetric or symmetric test, weak
> or string version, we'll get something that will work better than == or
> assertAlmostEqual, and it will do the right thing in the vast majority of
> cases.

Personally, I'd agree with this.

> I could live with, and indeed be happy with, any of the solutions on the
> table. My take from this thread is that most people converged on the
> asymmetric option as the better choice, but Steven feels strongly that the
> symetric option is the way to go. I don't know if this is a stopper for
> anyone, though.
>
> Is there anyone that could only live with one of the options?
>
> (by live with, I mean think that we'd be better off with nothing in the
> standard lib that one of these options)
>
> Please speak.

Nope, I could manage with any of the options. (Disclaimer: I'm not
sure I've ever needed a function like this in practice, so my opinion
is of limited relevance. My concerns over details are more about
whether I'd find the function intuitive enough that I'd think of using
it instead of a quick abs(a-b)<1e-8 in toy examples).

> The other issue is whether to have a default that will return True for at
> least common uses of comparison to zero.
>
>  - I think it's better to be safe than sorry, and not let folks accidentally
> think they have a value close to zero that isn't really.
>
>  - Nathaniel thinks that it's better to provide a default that will give an
> answer for is close to zero that will at least work for common cases.
>
> I could live with what Nathaniel Proposes, and I believe he said he could
> live with what I propose -- so this is not a stopper. However, someone's
> going to need to come up with what that default value -- part of why I think
> it should be zero is that I have no idea if a small-compared-to-one default
> is reasonable.

As Nathaniel has come up with a lot of real-world cases where
comparing to zero is the issue, I think the new function needs to
handle that case properly. Deliberately choosing defaults that don't
suit a significant use case seems like a mistake. And saying that
users need to make an explicit choice each time seems to be to be
counter to the whole idea of a function which is designed to be used
by people who *don't* have the experience to make such choices...

Paul