RetroSearch Browse

Mon Jul 14 02:06:48 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-July/081059.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-July/081059.html below:

[Python-Dev] Proposed unittest changes