Ben Finney wrote:
> 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"?
If we can flip the word order in the language syntax, we can sure as
heck flip it in a method name :)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4