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

Michael Foord fuzzyman at voidspace.org.uk
Mon Dec 20 15:03:26 CET 2010

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.

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

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

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.

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

I told you how I think the diff should be generated and gave the reasons for it. If we use first / second in failure messages (but not necessarily in documentation or argument names - your objections notwithstanding) then the messages for the container asserts don't need to imply a direction (as Raymond suggested, wording like "in first but not in second" and "in second but not in first"). The string diffs are more problematic as they actually use difflib to generate the failure output.

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.

All the best,

Michael

Regards

Antoine.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

--

http://www.voidspace.org.uk/

May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

More information about the Python-Dev mailing list