Steve Holden <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com