Why?
There is no reason to assume that two integers which have the same value should be the same object?
On the other hand if you want to check if two integers are different, why would you check if they are different objects, after all they could still represent the same numerical value.
I mean I get that this is something that probably bites someone at the worst possible moment, but isn't this the case for most optimizations?
The problem is that if you allow too many of these inconsistencies, then you're almost destined to run into one of them. It's better to eliminate them while you still can.
Let's see. The first mistake is of course that the object identity operator is called "is", and should have been called something like "is-same-object-as".
Then, a is-same-object-as b, for integers could raise an error, as a and b are not objects.
If that's not desired (for some reason), then a is-same-object-as b could indeed return false in all cases, and that would at least be more consistent than returning true for integers smaller than some number and false otherwise.
I don't expect that's a language I'd enjoy. You may prefer Objective-C over Python.
> a is-same-object-as b, for integers could raise an error, as a and b are not objects.
That would be a greater inconsistency than the minor additional optimization for small integers. It's a Java performance optimization that has crept into the way you think about the data, impacting much more of your program than just "is-a-long-name".
On the other hand if you want to check if two integers are different, why would you check if they are different objects, after all they could still represent the same numerical value.
I mean I get that this is something that probably bites someone at the worst possible moment, but isn't this the case for most optimizations?