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

[Antoine Pitrou]

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.