Gabriel Grant wrote:
This gem from unittest.py is pretty much the opposite of "one obvious way":
# Synonyms for assertion methods assertEqual = assertEquals = failUnlessEqual assertNotEqual = assertNotEquals = failIfEqual assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual assertNotAlmostEqual = assertNotAlmostEquals = failIfAlmostEqual assertRaises = failUnlessRaises assert_ = assertTrue = failUnless assertFalse = failIf
Could these be removed for 3k?
There was a short discussion about this among some of those those present in the Python Core sprint room at PyCon today and most preferred the "assertEqual" form for [Not][Almost]Equal and Raises.
With assertFalse vs. failIf (and assertTrue vs. failUnless) there was far less agreement. JUnit uses assertTrue exclusively, and most people said they feel that using assertTrue would be more consistent, but many (myself included) still think failUnless and failIf are much more natural. Another issue with assertTrue is that it doesn't actually test for 'True', strictly speaking, since it is based on equality, not identity.
+1 on standardising on 'assert*' and removing 'fail*'.
+1 on making 'assertTrue' test for True rather than any non-false object (and vice versa for assertFalse)
For migration a simple subclass of TestCase that provides the old methods/semantics is trivial to write. No need for monkey-patching.
Its also interesting to note the original commit message:
r34209 | purcell | 2003-09-22 06:08:12 -0500 (Mon, 22 Sep 2003) [...]
- New assertTrue and assertFalse aliases for comfort of JUnit users
assertEqual (and its cousins) were already present at that point.
In any case, if the decision is made to not use failUnless, something still needs to be done with assert_ vs. assertTrue. assert_ seems somewhat better to me, in that it has fewer characters, but I think that a case could certainly be made to keep both of these.
I certainly don't have the authority to make a call on any of this, but if someone else decides what colour to paint this bike shed, I can try to get it done (hopefully with 2.6 warnings) tomorrow.
P.S. If you were in the sprint room and feel terribly misrepresented, please feel free to give me a swift kick both on-list and in person tomorrow morning. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...