nope :-)

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.

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.

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.

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.

I think that's it.

Perhaps folks could focus now on issues that they think are show stoppers.

Or bike-shed the parameter names and stuff, if you really want to paint a bike shed ;-)

-Chris