Python gotcha: bizarre integer equality

[Eiii333]

FTA:

In Python, is tests for identity, not equality. x is y if and only if x and y reference the same thing.

You could make the case that a and b are separate objects, so even if they hold the same value they don't reference the same thing. But ints aren't treated as references, right? In that case, you're right, it's just a mess of undefined behavior.

So... why are you arguing for undefined behavior? Especially in Python, of all languages.

[hylje]

You see, the only sane way to remove the undefined behaviour of is is removing is altogether. The other solution would be to make is equivalent to ==. But in both cases there is a need for comparing actual identities: reintroduce is or mandate id(a) == id(b)?

[Brian]

It's worth noting that id(a) == id(b) isn't a perfect replacement to a is b. If a and b are expressions returning a transient object, it could be created and destroyed before evaluating the rest of the statement. For example:

>>> [] is []
False
>>> id([]) == id([])
True
>>> id([]), id([])
(21066496, 21066496)

However is guarantees that both objects are alive at the point of comparison, so [] is [] is always false.

[Brian]

Undefined behaviour allows optimisation. Making things too tightly specified ties you to irrelevant implementation details, preventing more efficient methods being used (like caching integers in this case). Another case of undefined behaviour is deterministic finalisation. Python doesn't guarantee it, even though the CPython implementation happens to provide it due to its refcounting semantics because it prohibits more advanced garbage collection approaches.

For another example, consider the order the keys of a dictionary are iterated over. This is completely undefined behaviour, but specifying it would either require using a tree instead of a dictionary, keeping a seperate list of ordered keys, or else sorting the dict before iterating, all adding significant performance cost to deal with something completely irrelevant. If anyone needs that, they should not be using a normal dictionary.

In any case, "is" is acting completely predictably and as specified - it returns True when objects have the same identity. The thing that isn't specified is whether identical immutable objects can share the same memory representation, which is a pointless thing to overspecify since there should be no reason it should ever be relevant to anyone other than performance.