[Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
Guido van Rossum
guido at python.org
Sun Dec 19 05:23:49 CET 2010
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. :-(
On Sat, Dec 18, 2010 at 2:46 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
>> On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
>> ezio.melotti<python-checkins at python.org> wrote:
>>> Author: ezio.melotti
>>> Date: Sat Dec 18 21:00:04 2010
>>> New Revision: 87389
>>> #10573: use actual/expected consistently in unittest methods.
> Change was requested by M. Foord and R. Hettinger (and G.Brandl for b2).
>> IMHO, this should be reverted. The API currently doesn't treat these
>> arguments differently, so they should really be labeled "first" and
>> "second". Otherwise, the user will wrongly assume that the signature is
>> asymmetric and that they should be careful about which order they pass
>> the arguments in.
> The error report on assert failure *is* often asymmetrical ;=).
> From Michael's post:
> "This is particularly relevant for the methods that produce 'diffed' output
> on failure - as the order determines whether mismatched items are missing
> from the expected or additional to the expected."
> This change struck me as a nice bit of polishing.
> Terry Jan Reedy
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev