RetroSearch Browse

Mon Jul 14 12:05:22 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-July/081074.html

Nick Coghlan <ncoghlan at 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

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

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

[Python-Dev] Proposed unittest changes