[Python-Dev] Proposed unittest changes (original) (raw)

Ben Finney bignose+hates-spam at benfinney.id.au
Mon Jul 14 02:06:48 CEST 2008

Steve Holden <steve at holdenweb.com> writes:

Michael Foord wrote: > Adding the following new asserts: > > assertIn (member, container, msg=None) > assertNotIn (member, container, msg=None) > assertIs (first, second, msg=None) > assertNotIs (first, second, msg=None)

Please, let's call this one "assertIsNot". I know it's valid Python to say if a not is b: but it's a much less natural way of expressing the condition, and (for all I know) might even introduce an extra negation operation. "is not" is, I believe, treated as a single operator.

Dang. You're exactly right.

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"?

I know that part of the goal here is to have "preferably only one obvious way to do it", but I can see both those names as "the obvious way to do it". Is this an instance where the "preferably" clause must be exercised in the negative?

-- \ “Every sentence I utter must be understood not as an | `\ affirmation, but as a question.” —Niels Bohr | o_) | Ben Finney

More information about the Python-Dev mailing list