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

Antoine Pitrou solipsis at pitrou.net
Mon Dec 20 15:31:37 CET 2010

Le lundi 20 décembre 2010 à 14:03 +0000, Michael Foord a écrit :

On 20/12/2010 13:47, Antoine Pitrou wrote: > Le lundi 20 décembre 2010 à 13:00 +0000, Michael Foord a écrit : >> Ah man, we've nearly finished bikeshedding about the names of unittest >> assert methods so its time to move onto the names and order of the >> arguments. Really? > Apparently someone decided this bikeshedding was important enough to > make an SVN commit out of it. If you think it isn't worth discussing > then perhaps it wasn't worth changing in the first place :)

The only change was to use them consistently and the only code change was to re-order the arguments in a method that is new and not in any previous version of Python. You're arguing for a much bigger change.

No, I'm first of all arguing for a "first/second" or "a/b" argument naming. Which was exactly the case before the change that triggered this thread.

>> The only thing left to decide is then the order - (actual, expected) or >> (expected, actual). Raymond, myself, Guido and Ezio have all expressed a >> preference for (actual, expected). I like this comment from Raymond on >> the relevant issue [2]: >> >> I also tend to use actual/expected and find the reverse to be a >> form Yoda-speak, "assert 5 == x", "perhaps misread the prophecy was", etc. > Isn't it some kind of ethnocentric comment? "Natural" order is not the > same in all languages, and I don't see why "actual" should come before > "expected".

Agreement that actual, expected was preferred came from an American, a Dutchman, an Englishman and an Italian. :-)

I'm not sure what that's supposed to prove, unless you have problems with the idea that what is natural for a couple of people isn't natural for everyone. You also apparently missed that part:

> Now if you look at various TypeErrors raised in Python, the error > message is most often "expected, got". So there > expected always comes before actual, and apparently it was natural to > the authors of that code. Perhaps they are all Yoda-speakers.

As it is what unittest currently uses anyway you'll need more than "I don't see why" to reverse it.

unittest doesn't "use it anyway", since it used first/second before that change. Actually, as I pointed out, (expected, actual) is used in assertRaises in friends.

> And the problem here is that (actual, expected) is in reverse order of > the diff displayed on error. >

Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result.

Which, again, they don't. Let's see:

self.assertEqual(actual, expected)

AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c

The diff shows "expected - actual", but it would be logical (in your own logic) to display "actual - expected". The whole issue disappears if you drop this idea of naming the arguments "actual" and "expected".

I'm also against dropping the use of actual / expected concepts and terminology within unittest as I think they are useful. We don't necessarily need to use them in the failure outputs but it seems like you want them to be dropped altogether.

I'm saying that they cause confusion wrt. to the actual error display (as Guido also admitted). Feel free to come up with a solution that doesn't get rid of actual/expected, if that's what you want ;)

Regards

Antoine.

More information about the Python-Dev mailing list