Le lundi 20 décembre 2010 à 14:03 +0000, Michael Foord a écrit : > 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.
No, I'm first of all arguing for a "first/second" or "a/b" argument naming. Which was exactly the case before the change that triggered this thread. > >> 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. :-) I'm not sure what that's supposed to prove, unless you have problems with the idea that what is natural for a couple of people isn't natural for everyone. You also apparently missed that part: > > 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. > As it is what unittest currently uses anyway you'll need more than "I > don't see why" to reverse it. unittest doesn't "use it anyway", since it used first/second before that change. Actually, as I pointed out, (expected, actual) is used in assertRaises in friends. > > 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. Which, again, they don't. Let's see: self.assertEqual(actual, expected) AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c - e + d The diff shows "expected - actual", but it would be logical (in your own logic) to display "actual - expected". The whole issue disappears if you drop this idea of naming the arguments "actual" and "expected". > 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. I'm saying that they cause confusion wrt. to the actual error display (as Guido also admitted). Feel free to come up with a solution that doesn't get rid of actual/expected, if that's what you want ;) Regards Antoine. _______________________________________________ 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/archive%40mail-archive.com