Consider shape_key_add(). In the Python api it is listed in two places: bpy.ops.object.shape_key_add bpy.types.Object.shape_key_add
. bpy.ops.object.shape_key_add is coded in file object_shapekey.c as void OBJECT_OT_shape_key_add(wmOperatorType *ot)
. bpy.types.Object.shape_key_add is coded in file rna_object_api.c as
It looks like shape_key_add() is supposed to be looked at as a member of class bpy.types.Object, and an instance of Object is declared in Class bpy.types.Operator, and that shoouuld mean that, from the Python api perspective, there is only one method called shape_key_add() - I think? And maaybe because of the Python binding process, it was more practical just to recode certain functions like shape_key_add() - I guess? Btw, I’m not real knowledgeable of the Python language.
. Question: Why are some operators, like shape_key_add(), coded multiple times ? Question: Is shape_key_add() supposed to be considered a single method - from a purely Python api perspective ?
I am interested in making certain operators and I want to get a better idea about where in the codebase should the operator code be duplicated.
Are the different occurences of functions, like shape_key_add() supposed to be considered two different, yet similar, functions in Python or are they supposed to be looked at as exactly the same in Python ?
IF they are supposed to be considered the same funtions, only within Python of course, then what are some of the unexpected side effects that could occur in api functions that wouldn’t occur within operators ?
In some cases they are the same, but not always. There are also many operators that have no corresponding API function, and vice versa. They just have different purposes.
It’s operators that might have unexpected side effects for Python scripts. They are just more high level typically, working on selected objects and doing many operations at once. For Python scripts it’s better to do individual operations on a single specified object.