Nick Coghlan <ncoghlan@gmail.com> writes:
Ben Finney wrote:
The problem is, that makes it quite inconsistent with other "not" uses (such as "assert_not_equal", "assert_not_in", etc.) I would really prefer that all these "not" uses be gramatically consistent for predictability. Is this a case where "assert_is_not" should exist alongside "assert_not_is"?
If we can flip the word order in the language syntax, we can sure as heck flip it in a method name :)
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. -- \ “Instead of having ‘answers’ on a math test, they should just | `\ call them ‘impressions’, and if you got a different | _o__) ‘impression’, so what, can't we all be brothers?” —Jack Handey | Ben Finney