[Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

Nick Coghlan ncoghlan at gmail.com
Wed Dec 22 02:12:29 CET 2010

On Tue, Dec 21, 2010 at 11:17 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 21/12/2010 01:57, Nick Coghlan wrote:
>> My own +1 goes to keeping the actual/expected terminology (and
>> ordering) and adjusting the diffs accordingly (with a header noting
>> that the diff is old=expected, new=actual).
> Well we don't have consensus. Whatever we do we need to be consistent, and
> in the absence of an agreement about a change we should at least make all
> the behaviour and documentation consistent.
> From this discussion and the discussion on the issue tracker:
> Myself, Nick Coghlan and Ezio Melotti prefer (actual, expected)
> Raymond like (actual, expected) but would be happy with symmetrical diffs
> Guido prefers the (actual, expected) ordering but prefers diffs to show the
> other way round
> R David Murray agreed with Guido
> Terry Reedy liked the change
> Glenn Linderman wants (actual, expected) and diffing to follow that
> Ron Adam ditto
> Symmetrical diffs (element in first not in second, element in second not in
> first) solves the problem without imposing an order on the arguments.
> Actually unittest *has* used (first, second) to refer to the arguments to
> asserts pretty much since its inception. Losing the (actual, expected)
> terminology is a cost of this but unittest hasn't emphasised this
> terminology in the past (as I thought it had).

I actually agree with Guido that anything we do is going to be
suboptimal in some way. Encouraging the actual/expected ordering and
updating the diff output so "expected=old" strikes me as least bad,
but using the neutral first/second terminology and doing the diffs as
"first=old" wouldn't be terrible (although I'm personally -0 on it
because it encourages putting the expected value first in order to get
the diffs the right way around when an error occurs).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list