"is" is a pretty special operation in python. The only thing it can be reliably used for is to check if two things refer to the exact same object. Retrieving the same value twice has no guarantees about returning the same object twice.
"is" causes so much confusion I'm not sure if it should've been a part of the language in the first place. It can always be substituted with the more explicit
`1 is 1` gives `True` in CPython because numbers in range -5..300 are reused (not 100% about the exact range). This is not a problem, because there's no practical need to compare identities of two integers. There is however a need to compare identities of two bones, for example if you want to parent all selected bones to the active bone, but the active bone is also selected, so when you iterate, you check if the iterator `is not` the active bone before parenting.
Of course in the end of the day it's not a problem that you have to use equality operator instead for bpy wrappers. It's just surprising, non-idiomatic in Python, where a developer unaware of this gotcha would rather think using `==` can give `True` for two different bones but similar enough that the `__eq__()` returns `True`.
Substituting with `id` solves nothing and goes against Python's spirit.
I know why "is" works like it does. I'm just pointing out that having two equal objects from the same source not be the same object IS idiomatic python. The reference implementation does it with something as basic as integers!
Substituting with id goes against the python spirit because "is" exists. I'm trying to argue that "is" probably shouldn't exist. It's a bit of a footgun.
You are simply wrong here. The `is` comparison you show is a CPython specific quirk, and not part of the Python philosophy. How could you think otherwise if it's inconsistent and doesn't apply to all numbers in the same way?
"is" causes so much confusion I'm not sure if it should've been a part of the language in the first place. It can always be substituted with the more explicit