On Tue, Jan 27, 2015 at 10:37 AM, Guido van Rossum <guido@python.org> wrote:
By now can't you summarize the reasons that others have brought up?


I can try ;-) --probably not until this evening though.

 > Because we want it to be able to do something sane when comparing to zero --

<snip>

I don't think you can have this always be sane. For someone who for whatever reason is manipulating quantities that are in the range of 1e-100, 1e-12 is about as large as infinity.

Exactly why I favor having the abs_tolerance default to zero.

 
I think my reasoning comes down to the same rule I often use to decide whether we need one function or two -- if in every use case you always know whether you need version A or version B, then it's better to have two functions rather than a single one with a flag to request A or B.

And isn't it the case that whenever you are comparing to zero, you *know* that you are comparing to zero, and you *must* specify an absolute tolerance (otherwise it's not a use case at all)?

I really appreciate this API design approach, and in this case I started out with that idea. But I think this is likely to be used where you need to test a bunch of values with single function/set of parameters. In TestCase.assertIsCloseTo, as well as home grown loops and comprehensions.

IIUC, numpy doesn't design APIs this way.

I'm not sure numpy's API is exactly designed at all ;-)
 
-Chris
 
--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov