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

Ron Adam rrr at ronadam.com
Mon Dec 20 17:47:33 CET 2010



On 12/18/2010 04:46 PM, Terry Reedy 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
>>>
>>> Log:
>>> #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.

I've always presumed it would make a difference in error displayed anyway.


> 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.

I like ("actual", "expected") in the asserts.  It matches my expected 
ordering of "input"/"output" and how I use comparisons in 'if' statements.

I feel it is more important that the diffs are consistent with other diffs 
in python.

So (for me), changing the asymmetrical output to be symmetrical would be in 
the category of foolish consistency because changing that, introduces other 
inconsistencies I'd rather not have.

It doesn't bother me that the functions arguments aren't the same order of 
the diffs as long as the labels and wording are obvious enough in the 
messages.  So maybe the diff output can be improved a bit instead of 
changing the terms and ordering.

Ron


More information about the Python-Dev mailing list