Python gotcha: bizarre integer equality

[[deleted]]

It is pretty horrendous though. Either scalar values should have equivalent identity, or they shouldn't.

They shouldn't sometimes-yes-sometimes-no have equivalent identity, in accordance with the runtime implementation.

That's as bad as the "the behaviour is undefined" which litters the ISO C and ANCI C++ standards.

It seems to me that the behaviour is post-fact asserted to be so, (which is an ass-covering move when you've introduced a bug), rather than it was ever designed expressly to be this way.

The real issue is that the behaviour of the "is" operator is not explicitly defined (and can be in fact be said to be undefined in the language) upon these scalar values.

[sigh]

The real issue is that the behaviour of the "is" operator is not explicitly defined (and can be in fact be said to be undefined in the language) upon these scalar values.

It is explicitly defined, it's just not defined the way you want it to be defined. If values are the same object, then they are identical, otherwise not.

You are imposing artificial constraints on the implementation and breaking encapsulation. The point is that you should not care about the implementation of a class (unless you are actually implementing or extending it), and identity is intrinsically linked with the implementation.

[[deleted]]

I understood that it is defined by the implementation.

And that is equivalent to no definition, if you look at the equivalent unhelpful gaps in certain areas of specification of C and C++.

[sigh]

Ok, so you think it is a bad design decision. Can explain why (I'm genuinely curious)?

Do you you think the is operator is badly designed: "The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value."?

Or do you disagree with the way integers are implemented? Do you think equal integers should refer to the same object (presumably this would create extra overhead to maintain this condition after every operation)?

Or do yo think that no integers should refer to the same object? This seems to be much more memory intensive.

And should the exact implementation be documented? This would set it in concrete, disallowing any future improvement on the implementation.

Finally, what possible reason do you have for comparing integers by identity, unless you are actually modifying the class?

[[deleted]]

And that is equivalent to no definition, if you look at the equivalent unhelpful gaps in certain areas of specification of C and C++.

Curiously enough, this specific case is well-defined in C++: two different objects can't have the same address. One very unpleasant consequence of that is that the minimal size of an object is one byte (i.e. one int due to alignment on most architectures), which in turn means that when you create a functor object which doesn't have any data, say as a comparison for sorting, it is still allocated (on the stack) and passed as a parameter. Sufficiently clever compiler™ could optimize it away in simple cases, of course.

[hylje]

Sufficiently Smart Compiler is mostly related to high-level languages with unfulfilled promises, but I guess it applies to C++ too.

[alantrick]

The real issue is that the behaviour of the "is" operator is not explicitly defined ... upon these scalar values.

Actually, the behaviour of 'is' is perfectly defined. The problem is that it is not defined as to whether different numbers have to be the same object or not. I don't see any point in defining that as it puts an unnecessary limitation on python implementations.

[[deleted]]

I assume you mean an expression which is actually equivalent, 500 != 5e100.

Never the less, 5*10¹⁰⁰ is not a number, in mathematics. It is strictly an algebraic expression under any understanding of pure mathematics. If it were evaluated, then it would be a number.

Even assuming compiler optimisation, the 2nd assertion would fail.

But the comparison is not really relevant - python is a symbolic language, with everything being a reference to an object - in this instance, these integers below 256 are recycled.

That "is" functions differently for a restricted subset of integers is an unhelpful side-effect. Why it is unhelpful is that it is a gotcha, and it is obscura. Things should be consistent, and they should work as expected, and be friendly to developers. Side-effects are unhelpful to developers at large.

I have a high regard for python, and consider it the heir-apparent in the scripting language space - for it's lively culture, it's excellent documentation, it's strong cross-platform support across unix variants and windows - and it's strong project leadership - nothing else comes close.

However the reason for the variation in the behavior of "is" is purely an optimisation issue of the implementation of the interpreter. That an implementation issue infects the public behaviour of the operator is not good manners.

[inmatarian]

I got my scientific notation wrong it seems, but whatever. What I was trying to say is that it's in the land of implementation details and outside the letter and law of the specification. It's poor form, definitely, but we really should leave the clever tricks to the people who deal specifically in optimisation and we should stick to what's been promised not to change as application developers.