unittest wart/bug for assertNotEqual

Discussion in 'Python' started by Zac Burns, Oct 20, 2009.

  1. Zac Burns

    Zac Burns Guest

    Using the assertNotEqual method of UnitTest (synonym for failIfEqual)
    only checks if first == second, but does not include not (first !=
    second)

    According to the docs:
    http://docs.python.org/reference/datamodel.html#specialnames
    There are no implied relationships among the comparison operators. The
    truth of x==y does not imply that x!=y is false

    The name assertNotEqual to me implies a check using !=. This
    misleading title can cause a programmer to think a test suite is
    complete, even if __ne__ is not define - a common mistake worth
    testing for.

    Python 2.6

    --
    Zachary Burns
    (407)590-4814
    Aim - Zac256FL
    Production Engineer (Digital Overlord)
    Zindagi Games
    Zac Burns, Oct 20, 2009
    #1
    1. Advertising

  2. On Oct 20, 6:20 pm, Zac Burns <> wrote:
    > Using the assertNotEqual method of UnitTest (synonym for failIfEqual)
    > only checks if first == second, but does not include not (first !=
    > second)


    It looks as though this is fixed in Python 2.7 (and also in 3.1):

    http://svn.python.org/view?view=rev&revision=71032

    --
    Mark
    Mark Dickinson, Oct 20, 2009
    #2
    1. Advertising

  3. On Tue, 20 Oct 2009 10:20:54 -0700, Zac Burns wrote:

    > Using the assertNotEqual method of UnitTest (synonym for failIfEqual)
    > only checks if first == second, but does not include not (first !=
    > second)
    >
    > According to the docs:
    > http://docs.python.org/reference/datamodel.html#specialnames There are
    > no implied relationships among the comparison operators. The truth of
    > x==y does not imply that x!=y is false
    >
    > The name assertNotEqual to me implies a check using !=. This misleading
    > title can cause a programmer to think a test suite is complete, even if
    > __ne__ is not define - a common mistake worth testing for.



    I was with you right up to the last six words.

    Whether it's worth changing assertNotEqual to be something other than an
    alias of failIfEqual is an interesting question. Currently all the
    assert* and fail* variants are aliases of each other, which is easy to
    learn. This would introduce a broken symmetry, where assertNotEqual tests
    something different from failIfEqual, and would mean users have to learn
    which assert* methods are aliases of fail* methods, and which are not.
    I'm not sure that's a good idea.

    After all, the documentation is clear on what it does:

    | assertNotEqual = failIfEqual(self, first, second, msg=None)
    | Fail if the two objects are equal as determined by the '=='
    | operator.
    |


    (Taken from help(unittest).)



    --
    Steven
    Steven D'Aprano, Oct 20, 2009
    #3
  4. Zac Burns

    Zac Burns Guest

    > I was with you right up to the last six words.
    >
    > Whether it's worth changing assertNotEqual to be something other than an
    > alias of failIfEqual is an interesting question. Currently all the
    > assert* and fail* variants are aliases of each other, which is easy to
    > learn. This would introduce a broken symmetry, where assertNotEqual tests
    > something different from failIfEqual, and would mean users have to learn
    > which assert* methods are aliases of fail* methods, and which are not.
    > I'm not sure that's a good idea.
    >
    > After all, the documentation is clear on what it does:
    >
    >     |  assertNotEqual = failIfEqual(self, first, second, msg=None)
    >     |      Fail if the two objects are equal as determined by the '=='
    >     |      operator.
    >     |
    >
    >
    > (Taken from help(unittest).)
    >
    >
    >
    > --
    > Steven
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >


    My preference would be that failIfEqual checks both != and ==. This is
    practical, and would benefit almost all use cases. If "!=" isn't "not
    ==" (IEEE NaNs I hear is the only known use case) then those could
    simply not use this method.

    It would not surprise me if changing this would bring to light many
    existing bugs.

    --
    Zachary Burns
    (407)590-4814
    Aim - Zac256FL
    Production Engineer (Digital Overlord)
    Zindagi Games
    Zac Burns, Oct 20, 2009
    #4
  5. On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote:

    > My preference would be that failIfEqual checks both != and ==. This is
    > practical, and would benefit almost all use cases. If "!=" isn't "not
    > ==" (IEEE NaNs I hear is the only known use case)


    numpy uses == and != as element-wise operators:


    >>> import numpy
    >>> a = numpy.array([10, 20, 30, 40])
    >>> b = numpy.array([10, 20, 31, 40])
    >>> a==b

    array([ True, True, False, True], dtype=bool)
    >>> a!=b

    array([False, False, True, False], dtype=bool)
    >>> not a!=b

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    ValueError: The truth value of an array with more than one element is
    ambiguous. Use a.any() or a.all()



    > then those could simply not use this method.


    I'm not so sure this is a good idea. Python specifically treats == and !=
    as independent. There's no reason to think that a class must have both,
    or that it's an error if it defines == without !=, or even that they are
    reflections of each other. numpy doesn't, and that's a pretty huge
    counter-example.


    > It would not surprise me if changing this would bring to light many
    > existing bugs.


    It would surprise me.


    --
    Steven
    Steven D'Aprano, Oct 20, 2009
    #5
  6. Zac Burns

    Ethan Furman Guest

    Steven D'Aprano wrote:
    > On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote:
    >
    >
    >>My preference would be that failIfEqual checks both != and ==. This is
    >>practical, and would benefit almost all use cases. If "!=" isn't "not
    >>==" (IEEE NaNs I hear is the only known use case)

    >
    >
    > numpy uses == and != as element-wise operators:
    >
    >
    >
    >>>>import numpy
    >>>>a = numpy.array([10, 20, 30, 40])
    >>>>b = numpy.array([10, 20, 31, 40])
    >>>>a==b

    >
    > array([ True, True, False, True], dtype=bool)
    >
    >>>>a!=b

    >
    > array([False, False, True, False], dtype=bool)
    >
    >>>>not a!=b

    >
    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > ValueError: The truth value of an array with more than one element is
    > ambiguous. Use a.any() or a.all()
    >
    >
    >
    >
    >>then those could simply not use this method.

    >
    >
    > I'm not so sure this is a good idea. Python specifically treats == and !=
    > as independent. There's no reason to think that a class must have both,
    > or that it's an error if it defines == without !=, or even that they are
    > reflections of each other. numpy doesn't, and that's a pretty huge
    > counter-example.
    >
    >
    >
    >>It would not surprise me if changing this would bring to light many
    >>existing bugs.

    >
    >
    > It would surprise me.
    >
    >


    Two issues: 1) Sounds like we should have two more Asserts --
    failIfNotEqual, and assertNotNotEqual to handle the dichotomy in Python;
    and 2) Does this mean (looking at Mark Dickinson's post) that 2.7 and
    3.1 are now broken?

    ~Ethan~
    Ethan Furman, Oct 20, 2009
    #6
  7. En Tue, 20 Oct 2009 19:57:19 -0300, Ethan Furman <>
    escribió:
    > Steven D'Aprano wrote:
    >> On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote:


    >>> My preference would be that failIfEqual checks both != and ==. This is
    >>> practical, and would benefit almost all use cases. If "!=" isn't "not
    >>> ==" (IEEE NaNs I hear is the only known use case)


    >> numpy uses == and != as element-wise operators:


    > Two issues: 1) Sounds like we should have two more Asserts --
    > failIfNotEqual, and assertNotNotEqual to handle the dichotomy in Python;
    > and 2) Does this mean (looking at Mark Dickinson's post) that 2.7 and
    > 3.1 are now broken?


    1) assertEqual and assertNotEqual test for == and != respectively. The
    failXXX methods are being deprecated. Why do you think we need more
    asserts?
    2) Not exactly, but there are still inconsistencies (e.g. assertDictEqual
    and assertMultiLineEqual use != instead of ==, and some assertion messages
    use the wrong terminology)

    --
    Gabriel Genellina
    Gabriel Genellina, Oct 22, 2009
    #7
  8. Zac Burns

    Ethan Furman Guest

    Gabriel Genellina wrote:
    > En Tue, 20 Oct 2009 19:57:19 -0300, Ethan Furman <>
    > escribió:
    >> Steven D'Aprano wrote:
    >>> On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote:

    >
    >>>> My preference would be that failIfEqual checks both != and ==. This is
    >>>> practical, and would benefit almost all use cases. If "!=" isn't "not
    >>>> ==" (IEEE NaNs I hear is the only known use case)

    >
    >>> numpy uses == and != as element-wise operators:

    >
    >> Two issues: 1) Sounds like we should have two more Asserts --
    >> failIfNotEqual, and assertNotNotEqual to handle the dichotomy in
    >> Python; and 2) Does this mean (looking at Mark Dickinson's post) that
    >> 2.7 and 3.1 are now broken?

    >
    > 1) assertEqual and assertNotEqual test for == and != respectively. The
    > failXXX methods are being deprecated. Why do you think we need more
    > asserts?


    Ignorance, of course. :) I didn't know those were there. Hopefully
    the OP will also now realize those are there.

    > 2) Not exactly, but there are still inconsistencies (e.g.
    > assertDictEqual and assertMultiLineEqual use != instead of ==, and some
    > assertion messages use the wrong terminology)
    Ethan Furman, Oct 22, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Rubin

    genexp surprise (wart?)

    Paul Rubin, May 26, 2006, in forum: Python
    Replies:
    7
    Views:
    436
    Mel Wilson
    May 26, 2006
  2. Lawrence D'Oliveiro

    Python syntax wart

    Lawrence D'Oliveiro, Sep 9, 2007, in forum: Python
    Replies:
    32
    Views:
    974
    Carl Banks
    Sep 10, 2007
  3. Paul  Moore
    Replies:
    1
    Views:
    384
    Paul Moore
    Oct 14, 2008
  4. Roedy Green

    final and constructor, a Java Wart

    Roedy Green, May 2, 2009, in forum: Java
    Replies:
    14
    Views:
    568
    Albert
    May 4, 2009
  5. Chris Angelico

    Re: Python wart

    Chris Angelico, Nov 1, 2013, in forum: Python
    Replies:
    9
    Views:
    86
    Peter Cacioppi
    Nov 2, 2013
Loading...

Share This Page