This is kinda funny.
E.g. you could on a 32-bit machine reserve the least significant bit to mark an integer, and if it is set the high 31 bits are treated as a 31-bit integer instead of a pointer. Since your objects are likely bigger than a byte, you don't actually need all 32 bits for addresses and thus don't even loose addressable memory space. On 64bit machines you can do it even more, since they are far from being able to use all bits for actual memory, and you might even fit a short string or other more complex type in there.
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?
a = integer, b = same integer
a is b
The inconsistency is that the two separate variables reference the same object just because the values are the same.
In general, you shouldn't care about identity (is), just about value comparison (==).
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".
>>> isinstance(1, object)
I bought a book “Teach Yourself C in 21 days” and “OS/2 2.0 PM programming” Because I couldn’t afford anything more, everything in the game I created, Galactic Civilizations, could be found in those 2 books. [...] Let me give you an example – in GalCiv on OS/2, each star ship is actually a full blown window that is of style SS_ICON. So when you move a ship in the game, I’m just using WinSetWindowPos to move the ship X,Y coordinates. There’s no “graphics” in the game per se, just all icons being moved around. That’s because I couldn’t afford any more books than those two and they didn’t cover graphics programming, just icons and window movement.
By the way, OmniGraffle is also great for drawing graphs on the Mac.
Why not reinterpret_cast<PyArrayObject * > here?
(extra spaces are so Hacker News doesn't make this italics)