[Python-Dev] Proposed unittest changes
ncoghlan at gmail.com
Mon Jul 14 15:17:59 CEST 2008
Steve Holden wrote:
> Ben Finney wrote:
>> To be clear, I take it you're in favour of the following names (with
>> no aliases):
>> assert_equal assert_not_equal
>> assert_is assert_is_not
>> assert_in assert_not_in
>> assert_almost_equal assert_not_almost_equal
>> and so on; i.e. that 'assert_is_not' breaks the obvious pattern set by
>> the others, in the interest of matching Python's 'is not' grammar.
> Well, I'd have said "in the interest of reading correctly in English",
> though I have to acknowledge this may not be an issue for many Python
> users whose first language not is English. "assert_not_is" is just
> dissonant to my ears.
The two reasons aren't that far apart, given that Python's grammar uses
"is not" because it makes more sense in English. One thing to remember
is that the word 'is' is actually implied in all of the contracted
phrases above other than those already including it explicitly.
"x is equal to y"
"x is not equal to y"
"x is y"
"x is not y"
"x is in y"
"x is not in y"
"x is almost equal to y"
"x is not almost equal to y"
As for which phrasing I personally prefer, unit tests and method names
are areas where I'm quite happy to paint the bike shed the same colour
as the house :)
P.S. Deciphering that somewhat strained metaphor: I don't have a strong
preference with regards to the unit test method names. While I tend to
go with the assert* variants when left to my own devices, I have no
problem sticking to the fail* variants when updating a test that uses
them. Camel-case vs underscores in method names isn't something that
particularly worries me either.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev