RetroSearch Browse

Sat Oct 30 17:42:58 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-October/105084.html

On 30/10/2010 02:41, Steven D'Aprano wrote:
> Raymond Hettinger wrote:
>> The API for the unittest module has grown fat (the documentation
>> is approaching 2,000 lines and 10,000 words like a small book). I 
>> think we can improve learnability by focusing on the most important 
>> parts of the API.
>>
>> I would like to simplify and clean-up the API for the unittest module
>> by de-documenting assertSetEqual(), assertDictEqual(),
>> assertListEqual, and assertTupleEqual().
>
> While you're at it, what do you think of assertAlmostEqual? Is there a 
> use-case for it as it exists now?
>
> As I see it, it suffers from a number of problems:
>
> (1) Comparing floats for equality to some number of decimal places is 
> rarely (never?) the right way to do it. Comparison to some number of 
> significant figures would be better. Specifying an absolute or 
> relative error would be better still.
>

I agree, comparing floats to a specific number of decimal places has 
almost always been useless to me. What would be nice would be a 'delta' 
keyword argument allowing you to specify a difference instead. That 
could also allow you to compare non-numeric objects like times as well.

Now where are the keys to that time machine...

http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertAlmostEqual

All the best,

Michael Foord

> (2) This leads people to write the wrong test, because 
> assertAlmostEqual exists and is easy to use, while the right test is 
> tricky and requires better understanding of floating point issues.
>
> Example: I recently wrote tests using assertAlmostEqual where I 
> specified places=12, because my code should have been accurate to 12 
> significant figures. Worked fine for small floating point, but when I 
> started testing values of the order of 10000, my tests started 
> failing, because although it was correct to > 12 significant figures, 
> five of those figures were not decimal places.
>
> (3) In the rare case that mere rounding is the right way to compare 
> for approximate equality, assertAlmostEqual doesn't save you much: a 
> handful of characters, that's about all.
>
> self.assertAlmostEqual(x, y, places=n)
>
> vs.
>
> self.assertEqual(round(x, n), round(y, n))
>
> (Specifying the number of decimal places is keyword-only in 3.1. To 
> me, that seems to be a gratuitous change from 2.x, where it could be 
> specified as a positional argument.)
>
>
>

-- 
http://www.voidspace.org.uk/

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-October/105084.html below:

[Python-Dev] Cleaning-up the new unittest API