On 27 January 2015 at 04:25, Chris Barker <chris.barker@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