[Python-ideas] Make "is" checks on non-singleton literals errors

Guido van Rossum guido at python.org
Mon Oct 8 22:07:37 CEST 2012


On Mon, Oct 8, 2012 at 12:59 PM, Masklinn <masklinn at masklinn.net> wrote:
> On 2012-10-08, at 21:48 , Guido van Rossum wrote:
>> On Mon, Oct 8, 2012 at 12:44 PM, Mike Graham <mikegraham at gmail.com> wrote:
>>> I regularly see learners using "is" to check for string equality and
>>> sometimes other equality. Due to optimizations, they often come away
>>> thinking it worked for them.
>>>
>>> There are no cases where
>>>
>>>    if x is "foo":
>>>
>>> or
>>>
>>>   if x is 4:
>>>
>>> is actually the code someone intended to write.
>>>
>>> Although this has no benefit to anyone but new learners, it also
>>> doesn't really do any harm.
>>
>> I think the best we can do is to make these SyntaxWarnings. I had the
>> same thought recently and I do agree that these are common beginners
>> mistakes that can easily hide bugs by succeeding in simple tests.
>
> How would the rather common pattern of using an `object` instance as a
> placeholder be handled? An identity test precisely expresses what is
> meant and desired in that case, while an equality test does not.

It wouldn't be affected. The warning should only be emitted if either
argument to 'is' is a literal number or string. Even if x could be an
object instance I still don't see how it would lend meaning to "if x
is 4:".

> An other one which seems to have some serious usage in the stdlib is
> type-testing (e.g. collections.abc, decimal or tests of exception types).
> Without type inference, I'm not too sure how that could be handled
> as syntactic warnings, and as above an identity test expresses the
> purpose of the code better than an equality one.

Looks like you're mistaking the proposal for "reject 'is' whenever
either argument is a numeric or string value". The proposal is meant
to look at the source code and only trigger if a *literal* of those
types is used.

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list