+1 to assert* from me. the fail* variants always feel like double-negatives. I also always use assertTrue instead of assert_. But I don't care enough to argue about it. :)
On Wed, Mar 19, 2008 at 2:24 AM, Gabriel Grant <[EMAIL PROTECTED]> wrote: > Hi all, > > 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. > > 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. > > Cheers, > > -Gabriel > > 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/jyasskin%40gmail.com > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ _______________________________________________ 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/archive%40mail-archive.com
