On 12/24/2010 02:03 PM, Raymond Hettinger wrote:
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
On 12/24/2010 11:09 AM, Michael Foord wrote:
On 22/12/2010 02:26, Terry Reedy wrote:
On 12/21/2010 7:17 AM, Michael Foord wrote:
My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs.
Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments.
Where applicable, I prefer this as unambiguous output headings.
Could you explain what you mean?
I was referring back to an output example symmetric diff that was clipped somewhere along the way:
In x not in y: ... In y not in x: ...
rather than just using -,+ prefixes which are not necessarily self-explanatory. 'Not applicable' would refer to output from difflib which necessarily is ordered.
FWIW, I think + and - prefixes are much better for diffs that some made-up verbiage. People are used to seeing diffs with + and -. Anything else will be so contrived that it's net effect will be to make the output confusing and hard to interpret.
If you want, add two lines of explanation before the diff: + means "in x, not in y" - means "in y, not it x"
The notion of "making symmetric" can easily get carried too far, which a corresponding loss of useability.
I agree with this also.
I don't understand the effort to make the tests be symmetric when many of the tests are non-symmetric. (see list below)
I think the terms expected and actual are fine and help more than they hurt. I think of these as "actual result" and "expected result". A clearer terminology might be "expr" and "expected_result".
Where a tests can be used *as if* they are symmetric, but the diff context is reversed, I think that that is ok. It just needs a entry in the docs that says that will happen if you do it. That won't break tests already written.
Also notice (in the list below) that the use of 'a' and 'b' do not indicate a test is symmetric, but instead are used where they are *not-symmetric*. First and second could be used for those, but I think 'a' and 'b' have less mental luggage when it comes to visually seeing the meaning of the method signature in those cases.
Tests where the order is not important usually use numbered but like arguments, such as "expr1" and "expr2" or "list1" and "list2". This makes sense to me. "obj1" and "obj2" are just two objects.
The terms "x in y" and "x not in y" look like what you should get from containment or regex asserts.
I guess what I'm try to say is think of the whole picture when trying to make improvements like these, an idea that works for one or two things may not scale well.
Non-symmetric assert methods.
assertDictContainsSubset(self, expected, actual, msg=None) assertFalse(self, expr, msg=None) assertGreater(self, a, b, msg=None) assertGreaterEqual(self, a, b, msg=None) assertIn(self, member, container, msg=None) assertIsInstance(self, obj, cls, msg=None) assertIsNone(self, obj, msg=None) assertIsNotNone(self, obj, msg=None) assertLess(self, a, b, msg=None) assertLessEqual(self, a, b, msg=None) assertNotIn(self, member, container, msg=None) assertIsInstance(self, obj, cls, msg=None) assertIsNone(self, obj, msg=None) assertIsNotNone(self, obj, msg=None) assertNotIn(self, member, container, msg=None) assertNotIsInstance(self, obj, cls, msg=None) assertRegex(self, text, expected_regex, msg=None) assertNotRegexMatches(self, text, unexpected_regex, msg=None) assertRaises(self, excClass, callableObj=None, *args, **kwargs) assertRaisesRegex(self, expected_exception, expected_regex, callable_obj=None, *args, **kwargs) assertRegex(self, text, expected_regex, msg=None) assertTrue(self, expr, msg=None) assertWarns(self, expected_warning, callable_obj=None, *args, **kwargs) assertWarnsRegex(self, expected_warning, expected_regex, callable_obj=None, *args, **kwargs)