unittest: Improve self.assert(Not)AlmostEqual(s)

[AlexWaygood]

first and second can be any values where second can be subtracted from first, and the result of this operation can be safely passed to abs(), and the result of the absing can be safely compared with float. https://github.com/python/cpython/blob/93310879665368445f95df2f3d9be7fb82435248/Lib/unittest/case.py#L904

There was also an additional error in the stub: places and delta cannot both be non-None. If they are, the runtime raises an exception.

Fixes #7891

[Akuli]

How exactly are datetimes supposed to work?

>>> import unittest
>>> import datetime
>>> c=unittest.TestCase()
>>> c.assertAlmostEqual(datetime.datetime.now(), datetime.datetime.now())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/unittest/case.py", line 876, in assertAlmostEqual
    if round(diff, places) == 0:
TypeError: type datetime.timedelta doesn't define __round__ method

[AlexWaygood]

How exactly are datetimes supposed to work?

>>> import unittest
>>> import datetime
>>> c=unittest.TestCase()
>>> c.assertAlmostEqual(datetime.datetime.now(), datetime.datetime.now())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/unittest/case.py", line 876, in assertAlmostEqual
    if round(diff, places) == 0:
TypeError: type datetime.timedelta doesn't define __round__ method

Good spot. Looks like it only works if delta is specified:

>>> import unittest
>>> import datetime
>>> c = unittest.TestCase()
>>> d1 = datetime.datetime.now()
>>> d2 = datetime.datetime.now()
>>> c.assertAlmostEqual(d1, d2, delta=datetime.timedelta(hours=1))
>>> 

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[Akuli]

A couple thoughts about our tests in general:

• The tests work very well for pull requests like this one :) I was going to write my own tests as part of reviewing this, but it was nice that they already existed.
• I ran this test file with Python, making sure to get a runtime error whenever there's a type ignore comment. Ideally we would automate that somehow, but it doesn't seem to be worth the effort because we don't have that many tests.
• The error codes in tests are pretty much noise to me. I ignore them. I don't really care whether "wrong argument types" is a call-overload or arg-type error.

[AlexWaygood]

I ran this test file with Python, making sure to get a runtime error whenever there's a type ignore comment. Ideally we would automate that somehow, but it doesn't seem to be worth the effort because we don't have that many tests.

Oh, interesting idea. Tests like this file especially are basically very doctest-esque, just without the >>> prompt.

The error codes in tests are pretty much noise to me. I ignore them. I don't really care whether "wrong argument types" is a call-overload or arg-type error.

Yes, and compounding this problem, there's the fact that we generally only include tests for the trickiest functions to write stubs for. These are usually the ones where mypy ends up emitting really weird error codes. E.g. loads of the ones in test_sum.py are [list-item], and that's really meaningless; we shouldn't be asserting that mypy should emit such a meaningless error code (and there's no real reason why we should be giving mypy special treatment in these tests either). It seemed like a good idea at the time, but it's probably time to call it a day on the error-codes-in-tests.