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
[email protected]
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
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
