[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 14:47:21 CET 2010

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

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

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.

And moreover, some methods such as assertRaises() already have their args in the (expected, actual) order.

If we do move to a more "agnostic" wording in the failure messages (whilst keeping actual / expected as argument names and in the documentation perhaps?) then I prefer first / second to a / b.

Well, no. The whole point of displaying results as a/b (or first/second) is that they map intuitively to the first and second args. If, however, you name those args "actual" and "expected", it becomes confusing.

Also, it wouldn't fix that your diff would still be in a weird order compared to the method args (unless you think it's fine to display an "expected - actual" diff).

Regards

Antoine.

More information about the Python-Dev mailing list