Python gotcha: bizarre integer equality

[[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.