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 -- I only used that because it's called "isclose" in the math module -- but no one's likely to think a math module function is about files... "we don't need another way to do it" Yes, we certainly do -- it was added to the math module (even though a large fraction of use cases would be testing), and something like this is in numpy, Boost, etc, and as the long debate about the PEP indicates -- it's not obvious how to do it -- I'd argue this is more necessary in unitest than most of the other asserts.... (and, sample size 1: a relatively new user offered to proofread the patch for me, and immediately said "hey this is great -- I've been needing this!" Frankly, the objections to adding new aseert methods are really a critique of the unittest API -- it is clearly DESIGNED to have specialized asserts for many common use cases. So I think we should either: Embrace the API and add useful asserts like this one. or Make a concerted effort (Primarily through documentation) to move toward a different API (or a different way to use the current one, anyway). Robert's posts about "matches" are a good start. In the meantime, maybe the way to go with this is to add it to assertAlmostEqual -- it gives folks the functionality, makes it discoverable, and doesn't add a new name. Any objections to that before I take the time to code that up? -Chris ---------- _______________________________________ 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
