[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Yes -- it was on me years ago to do this. Honestly, I haven't done it yet because I lost the momentum of PyCon, and I don't personally use unittest at all anyway. But I still think it's a good idea, and I'd like to keep it open with the understanding that if

[issue27198] Adding an assertClose() method to unittest.TestCase

Vedran Čačić added the comment: An important point nobody made, as far as I can see: * the main usability improvement justifying math.isclose is that you don't know the order of magnitude of your correct value--it could be anything (even infinite), and the manner of comparison depends on it.

[issue27198] Adding an assertClose() method to unittest.TestCase

Gregory P. Smith added the comment: I agree with the decision, assertAlmostEqual is where the feature belongs. >From a practical point of view I suspect a lot of people who want this in the >wider world today use just `assert math.isclose(...)` despite the less useful >error message.

[issue27198] Adding an assertClose() method to unittest.TestCase

Irit Katriel added the comment: To summarize the discussion: There were objections to adding assertClose, but more agreement for adding an option to assertAlomstEqual that does the equivalent. Chris was to come back with an implementation (that was in 2016). Are we still pursuing this or

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Thanks Robert. I'll try to find time to re-do the patch soon. There was enough resistance to the whole idea that I wanted some confirmation that is was worth my time to do that! Stay tuned. -- ___ Python tracker

[issue27198] Adding an assertClose() method to unittest.TestCase

Robert Collins added the comment: Chris, I suggested altering assertAlmostEqual in http://bugs.python.org/issue27198#msg267187 :) - I took your agreement with that as a good thing and didn't reply because I had nothing more to add. IMO the status of this issue is as you indicated: you needed

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Did my comments not get posted, or are they not being read? Anyway: Could we keep the issues separate here? 1) If you don't like the name, propose another name -- no none has defended this name since an objection was first raised. I"m sure we can find one that

[issue27198] Adding an assertClose() method to unittest.TestCase

Berker Peksag added the comment: I agree with Raymond. I doubt most of the unittest users would ever need a builtin assertClose() method in unittest. I suggest closing this as 'rejected'. -- nosy: +berker.peksag ___ Python tracker

[issue27198] Adding an assertClose() method to unittest.TestCase

Raymond Hettinger added the comment: > Embrace the API and add useful asserts like this one. This kind of philosophy is going to lead to egregious API expansion, making Python harder to learn and remember. You're suggesting that we have a nearly zero resistance to adding new assert variants.

[issue27198] Adding an assertClose() method to unittest.TestCase

Changes by Pam McA'Nulty : -- nosy: +Pam.McANulty ___ Python tracker ___ ___

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Thanks Raymond. Damn! I wrote a nice comprehensive note, and my browser lost it somehow :-(. Here's a shorter version: "FWIW, I find assertClose easy to misinterpret. At first, it looks like an assertion that a file is closed." sure -- we can find a new name

[issue27198] Adding an assertClose() method to unittest.TestCase

Raymond Hettinger added the comment: FWIW, I find assertClose easy to misinterpret. At first, it looks like an assertion that a file is closed. And once you mentally pronounce it like "close something that is open", it is harder to make the jump to "close as in nearby". Also, I feed there

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: """w.r.t. error messages, a regular function that raises AssertionError with a nice message will be precisely as usable.""" sure -- I totally agree -- but that's not the current unittest API :-( where would you put it? How would people find it and know to use

[issue27198] Adding an assertClose() method to unittest.TestCase

Robert Collins added the comment: Future direction: hamcrest style matchers. You can read more about them in the context of unittest https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers -

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Would that make folks more amenable to adding more "specialized" asserts? If so, then sure. I don't know that it takes a PEP (I hope not) but it would be good to have some guidance as to the direction we want unittest to take written down somewhere. --

[issue27198] Adding an assertClose() method to unittest.TestCase

R. David Murray added the comment: I raised the same point on that issue, and the answer as I understand it is that we want to change the API by making the assert methods independent of the rest of unit test, so I think Serhiy was seeing the mixin as a move in that general direction.

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: thanks, that's Issue27152 if anyone's curious. Though I have no idea why you'd want it in a mixin, rather than just there. But sure, this could be "bundled" in with that. Perhaps it's time for a broader discussion / consensus about the future of the unittest

[issue27198] Adding an assertClose() method to unittest.TestCase

R. David Murray added the comment: On the name, I assumed it had something to do with files when I saw the issue title. I'm not sure that's enough of an argument against it, though. There's an issue where Serhiy is proposing a mixin with additional assert methods. If that has any traction

[issue27198] Adding an assertClose() method to unittest.TestCase

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

[issue27198] Adding an assertClose() method to unittest.TestCase

Robert Collins added the comment: Thanks for proposing this. I really don't want to add new assertions to unittest, and I certainly don't want to add narrow usage ones like this, nor ones that are confusingly named (this has nothing to do with files, but 'close' is a verb for files, just like

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: updated patch with the equation in the docs. -- Added file: http://bugs.python.org/file43165/assertClose.patch ___ Python tracker

[issue27198] Adding an assertClose() method to unittest.TestCase

Changes by R. David Murray : -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue27198] Adding an assertClose() method to unittest.TestCase

Chris Barker added the comment: Thanks, I'll add the equation to the docstring and docs. As for adding a rel_tol to assertAlmostEqual -- I think that's a bad idea -- it's a pretty different concept -- overloading the same method would be more confusing than anything else. in isclose(),

[issue27198] Adding an assertClose() method to unittest.TestCase

R. David Murray added the comment: The word description of the meaning of the tolerance attributes told me absolutely nothing. The equation from the math.islcose docs makes it prefectly clear. So I think the formula should be included in the documentation. assertAlomstEqual has a delta

[issue27198] Adding an assertClose() method to unittest.TestCase

New submission from Chris Barker: In py3.5, the math.isclose() function was added to the standard library. It can be used to compare floating point numbers to see if they are close to each other, rather than exactly equal. It's not a lot of code, but there are nuances that not every python