Nick Coghlan <[EMAIL PROTECTED]> 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
_______________________________________________
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
