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

[Michael Foord]

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<some type>, got<other type>". 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