This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deprecate assertNotAlmostEqual
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: ezio.melotti, michael.foord, pitrou, r.david.murray, rbcollins, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-05-01 16:53 by serhiy.storchaka, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (12)
msg292674 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-01 16:53
The purpose of the assertNotAlmostEqual() method of TestCase is not clear. This method is never used in the CPython testsuite (except tests for it itself), it is never mentioned in the bug tracker (except one general issue about mass renaming methods in TestCase). I have found only one usage of assertNotAlmostEqual() which is not testing its itself on GitHub [1], and in that case it would be better to use assertAlmostEqual() with correct expected result instead.

It seems to me that assertNotAlmostEqual() was added just "for symmetry", and there are no real cases for it. Deprecating and following removing it will make the API simpler.

[1] https://github.com/BrechtDeVlieger/Altran_courses/blob/d983b30b4dc1eac6905a71209037ed082330f7fe/Python%20fundamentals/Day1/Functions/test_temperature_ori.py
msg292679 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2017-05-01 17:26
I agree it's not *very* useful, but I don't see any benefit in getting rid of it either.
msg292680 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-05-01 17:39
Agreed with Michael.
msg292681 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-01 17:49
This will save time and memory of unittest users for reading the documentation, remembering it and trying to understand in which cases assertNotAlmostEqual() can be used. This will prevent them from using unsuitable method.

I found only one case of using assertNotAlmostEqual() in the wild, and it doesn't look a proper use. Do you have any cases in which it is useful?

Recently I did have a discussion with Giampaolo about changes to assertAlmostEqual() and assertNotAlmostEqual() [1]. If assertNotAlmostEqual() didn't exist this discussion would even not started. So this would save my and Giampaolo's time.

[1] https://github.com/python/cpython/pull/1331
msg292686 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-05-01 18:03
Any peculiarity that applies to assertNotAlmostEqual also applies to assertAlmostEqual, so I'm not sure how removing one but keeping the other would simplify anything.

Furthermore, such symmetry between positive and negative asserts is widespread in the unittest API, so this dual API is quite expected and nothing to be surprised about.
msg292687 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-05-01 18:11
Not only is not something to be surprised about, it would be surprising for it to be absent.  So the user cognitive overhead of removing it is quite possibly higher than that of it being there.
msg292689 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-05-01 18:18
There are 100 results in Google books alone. Are the books wrong (honest question, I did not check)?

They will be wrong if we remove it. ;)


I agree with Michael that assertNotAlmostEqual() doesn't hurt.
msg292691 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-01 18:51
> Any peculiarity that applies to assertNotAlmostEqual also applies to assertAlmostEqual, so I'm not sure how removing one but keeping the other would simplify anything.

There are use cases for assertAlmostEqual(). You can find examples in the CPython tests and in other open sources. Do you have use cases for assertNotAlmostEqual()?

> Furthermore, such symmetry between positive and negative asserts is widespread in the unittest API, so this dual API is quite expected and nothing to be surprised about.

This symmetry is not absolute. There are no asserts opposite to assertRaises(), assertWarns(), assertLogs() and assertCountEqual(), assertMultiLineEqual(), assertSequenceEqual(), etc. Some asserts are not symmetric by its nature. assertNotRaises() would be useless.

> There are 100 results in Google books alone. Are the books wrong (honest question, I did not check)?

Do these books have any use cases for assertNotAlmostEqual() or just enumerate the list of TestCase methods?
msg292695 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-05-01 19:00
> Do these books have any use cases for assertNotAlmostEqual() or just enumerate the list of TestCase methods?

I think this should be researched by the proponent of the change.
msg292698 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-01 19:34
Google finds only 16 books for me. I have reviewed them, and all of them just list assertion methods, copying the official documentation or one other. Often the book contains just one mention of assertNotAlmostEqual (not including the contents and the index). No books contain an example for assertNotAlmostEqual. They even don't mention the delta parameter added in 3.2.
msg292704 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2017-05-01 22:40
We've now spent more time debating the deprecation that we would have saved if it had been deprecated.

Deprecations cost user good will. Whilst I very much want to delete all assertions in favour of matchers, which would allow composed symmetry rather than the manual symmetry we have today.

Like michael I don't see any benefit in getting rid of it either. I don't believe it will make the API substantially easier to learn: the lack of symmetry increases special cases, so it will IMO make it harder to learn.

Unless you've new arguments to make about this, I think the ticket can be closed WONTFIX.
msg292713 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-02 05:06
If the absent of use cases is not good argument I close this issue. But this looks as a design mistake to me.
History
Date User Action Args
2022-04-11 14:58:45adminsetgithub: 74407
2017-05-02 05:06:44serhiy.storchakasetstatus: open -> closed
resolution: wont fix
messages: + msg292713

stage: resolved
2017-05-01 22:40:15rbcollinssetmessages: + msg292704
2017-05-01 19:34:05serhiy.storchakasetmessages: + msg292698
2017-05-01 19:00:37skrahsetnosy: - skrah
2017-05-01 19:00:07skrahsetmessages: + msg292695
2017-05-01 18:51:57serhiy.storchakasetmessages: + msg292691
2017-05-01 18:18:21skrahsetnosy: + skrah
messages: + msg292689
2017-05-01 18:11:05r.david.murraysetnosy: + r.david.murray
messages: + msg292687
2017-05-01 18:03:20pitrousetmessages: + msg292686
2017-05-01 17:49:28serhiy.storchakasetmessages: + msg292681
2017-05-01 17:39:00pitrousetnosy: + pitrou
messages: + msg292680
2017-05-01 17:26:52michael.foordsetmessages: + msg292679
2017-05-01 16:53:21serhiy.storchakacreate