3 ms·

Another example is how incompatible "bpy" is with Python idioms: in Python you're supposed to use `is` operator to compare identity, but since many objects in b

Another example is how incompatible "bpy" is with Python idioms: in Python you're supposed to use `is` operator to compare identity, but since many objects in bpy are short-lived wrappers of the actual C++ data, you have to use equality operator `==` instead. Otherwise you may run into such problems: >>> arm.bones['Bone'] is arm.bones['Bone'] False This is not a bug: https://developer.blender.org/T88914 https://developer.blender.org/T88914 As for operator overrides, you may find this list useful: https://blender.stackexchange.com/questions/248274/a-comprehensive-list-of-operator-overrides https://blender.stackexchange.com/questions/248274/a-compreh...

Doxin 5y ago
>>> 1 is 1 True >>> 999999 is 99999 False "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 id(a)==id(b)
- Etherlord87 5y ago
  `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.
  - Doxin 5y ago
    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.
    - Etherlord87 5y ago
      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?

Doxin 5y ago

>>> 1 is 1 True >>> 999999 is 99999 False "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 id(a)==id(b)

Etherlord87 5y ago
`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.
- Doxin 5y ago
  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.
  - Etherlord87 5y ago
    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?