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

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).

Cheers, Nick.

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

More information about the Python-Dev mailing list