[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

[Gabriel Grant]

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/archive%40mail-archive.com

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

[Gabriel Grant]

On Wed, Mar 19, 2008 at 5:02 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 6:24 PM, 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
>  >
>  [snip]
>
>  >  Could these be removed for 3k?
>
>  I agree with others who say that we shouldn't do this for Python 3k.
>  If we want to get rid of them, we should deprecate them, wait a
>  release or so, *then* remove them.

It seems to me if we want to remove this at some point, the time is
now. I'm not aware of anything starting off deprecated in 3k - my
impression is the whole point of 3k is to clean house.

Deprecation warnings can be put into 2.6 if people think thats
necessary, but the more important thing will be including it in 2to3.
I'm working on that right now, so if/when the actual wording is
finalized, it should just be a matter of changing around the order of
the function names in a dict.

-Gabriel
___
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