On 06/04/2015 11:26 AM, random...@fastmail.us wrote: > Of course, in CPython, the type of an object reference is PyObject *. > Which isn't invisible, unknown, or unknowable, either. > > If the value really were 23, the "is vs ==" problem wouldn't exist.
Surely two objects can hold the same value, or represent the same value (number), without *having* to be the same object. I don't see why people would assume, let alone demand that different objects representing the same value be the same actual object. Why should it even matter? Just relax and write code. I enjoy the forays into the the technical, and even the pedantic, but this is getting a bit silly. > x = 500 > y = x+1 > z = y-1 > > x and z (probably) point to two different objects. Sure. Python does not require objects representing numeric values to be singletons. And why worry anyway? The "is" operator is to be used in specific cases where identity is important (it's not important in the case of numbers). I'm sure an interpreter implementation could always guarantee that any object representing an integer value is always the same one, if a person thought it would make things faster. And in fact cpython does inter small values. But given that the interpreter is computing an actual, binary value under the hood during calculations, I can understand why it's just as easy to wrap up the answer in an object and hand it back to you, rather than try to guarantee a reference to an existing object of the same value. -- https://mail.python.org/mailman/listinfo/python-list
