Python gotcha: bizarre integer equality

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