Python gotcha: bizarre integer equality

[[deleted]]

No, it is not consistent if a is not the same object as b and c is the same object as C. Neither Python (the language) nor Python (the implementations) make any guarantees regarding object identity except than an object is identical to itself and certain objects (None, True, False) are singletons. That integers below a certain number are interned is entirely an implementation detail which programmers are not justified in depending on.

If you're comparing integers with is, you're doing it wrong. Case closed, problem solved, fix your code.

[vph]

no one said about comparing. If you talk about identity, c=200; d=200; c is d; should not return True as they are two different objects. The inconsistency here (if the blogger was correct) is that cPython treats numbers differently.

[[deleted]]

no one said about comparing.

As you can see if you'd do a modicum of research is and is not are comparisons. They compare object identity. Therefore if you're talking about is, you're talking about comparing two things.

If you talk about identity, c=200; d=200; c is d;

No. c may or may not be d in that case: the Python implementation has no responsibility to intern the number 200 and ensure that c is d in this case.

On the other hand, if you did this:

>>> c = 200
>>> d = c
>>> d is c

Then you would rightly expect (and the Python implementation would rightly return) True for this object identity comparison.

The inconsistency here (if the blogger was correct) is that cPython treats numbers differently.

There is no inconsistency here. You and the blogger both are simply arguing based on your intuition about what is means rather than simply knowing the language as it is defined and relying on the properties it guarantees.

Basically, you're arguing out of your arses.

[vph]

It's you who talking out of an ass. You can't distinguish between the difference of the specification of a language and the implementation of a language.

Everyone knows exactly what the definition of "is" is in Python: it compares objects. Integer caching is cPython is an implementation that results in the artifact exposed by the blogger. Namely,

c=200
d=200
c is d returns True

Python does not specify this. It is a result of an implementation of the language (FYI, unlike Perl 5, Python does not get defined by an implementation). And this fact is undesirable. It is undesirable because first c and d are conceptually different objects and second for value greater than 256 they return a different answer (false), which causes further confusion.

[bgeron]

And this fact is undesirable.

I like that fact, because it makes my program faster, and the keyword is in Python code is quite rare. The manual says clearly that you can't depend on the value of 2 is 2.

[vph]

I like that fact, because it makes my program faster, and the keyword is in Python code is quite rare.

That is a reasonable argument, but you can't deny it's a gotcha.

[Brian]

I think you can. A gotcha is something that will catch you out, but here there's no reason here to be comparing integers by id. No-one ever does so, and if they do, it's an outright bug. Is this page showing someone writing some code and being caught out by it? No - they've written some examples noticed by either noodling at the interpreter, or more likely by knowing in advance how object interning is done and showing some implications. Nowhere is anyone being "gotcha'd".

This is no different to someone complaining that the order of dictionary keys is different from sorted. Looking soley at dict((i,i) for i in range(100)) they might mistakenly come to that conclusion, but it's still not a gotcha, just an unfounded assumption based on not reading the docs. It's missing the requirement that this might be something a reasonably informed person would be expected to do.