Chris Barker added the comment: I'm not sure it's confusing --what would "close" mean for an assertion for a file? "assertClosed" would be confusing -- and an even more trivial assert :-). But we can bikeshed the name if we decide to put this in.
""" I certainly don't want to add narrow usage ones like this """ well, I can't say I like the unittest API either -- but "this would be just as well served with a function" applies to almost all the asserts in TestCase -- assertTrue? really? So unless we're going to deprecate that API, or at least document that you should be using simpler constructs: assert something rather than: self.assertTrue(something) then we might as well go with it and have a well supported API. """ I suggest a regular function that will raise AssertionError on failure""" where would that go? and what would it be called? and how would it be any better than: assert math.isclose(a,b) ?? The primary reason I think it should be there is discoverability. Folks will be looking through the testCase docs looking for the asserts they need. And they will find assertAlmostEqual -- and it will often be the wrong solution to their problem. Having the right solution be a first-class part of the API is "a good thing" And it does add a bit of useful information to the message -- knowing the tolerances used for the failing test really helps you know if it's a bug or too strict a test. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27198> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
