`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?
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.