On 19/12/2010 19:55, Raymond Hettinger wrote:
On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrousolipsis@pitrou.net wrote:
On Sat, 18 Dec 2010 20:23:49 -0800 Guido van Rossumguido@python.org wrote:
I may be unique, but I fear there is no great answer. On the one hand I almost always code it as e.g. assertEqual(actual, expected), which matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". On the other hand in those assert* functions that show a nice diff of two lists, when reading such a diff my expectation is that "old, new" corresponds to "expected, actual". Which then freaks me out until I realize that I coded it as "actual, expected"... And yet "expected, actual" still looks weird to me. :-(
This could be nicely resolved by renaming the arguments "a" and "b", and having the diff display "a, b". It's quite natural (both the diff ordering and the arguments ordering), and they are consistent with each other.
So 'a' stands for 'after' and 'b' for 'before', right? :-)
If you go down the a / b path instead of actual/expected, the diffs are straight-forward but some of the other output styles needed to be changed also (replace the messages for "unexpected" and "missing" elements to "things in a but not in b" and "things in b but not in a".
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?
I wouldn't use a/b but first/second  as they have a more obvious meaning.
However, I'm reluctant to move away from the actual/expected terminology. It's standard terminology for testing (used by all the other unit testing frameworks I looked at phpunit, JUnit and NUnit), but more importantly it is a useful way to think about testing - and one used by most devs I've worked with.
You fetch an 'actual' result by calling your code and compare it against a pre-computed 'expected' result. Hopefully the two are the same. Talking about your actual value and your expected value is a natural way to talk in testing, so it's a useful concept.
Once you use the 'actual' and 'expected' terminology you have a natural order for displaying failure message results: if an element is present in your actual but not in your expected then it is extra. If an element is in your expected but not in your actual then it is missing. Straightforward. (Of course it maybe that your actual is correct and it is your expected result needs correcting, that doesn't affect how failure messages should be presented though.)
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 :
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.
As the current ordering used within unittest is (actual, expected), to reverse it would be dumb (why should everyone using the current ordering reformat all their tests for the new order?).
So, -1 on dropping actual and expected. They're standard and useful terminology / concepts for testing.
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.
All the best,
 Interestingly unittest did use (first, second) for assert argument names back in 2.1 when it was added: http://svn.python.org/view/python/branches/release21-maint/Lib/unittest.py?r...
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...