Operators, as found in bpy.ops.<submodule>, are actually classes, instances of bpy.ops._BPyOpsSubModOp, which have functions poll, idname, idname_py and get_rna_type and property bl_options. (the real bpy.ops module containing the class is in scripts\modules\bpy\ops.py)
Additionally, the current signature for these operators (as functions) is actually incorrect because the positional-only arguments, override_context, execution_context and undo are optional (though must be in the provided order), e.g., override_context can be omitted when only providing execution_context or undo. The current function signature requires that override_context is provided if also providing execution_context or undo, which is incorrect.
When rewriting ops as classes, it might be possible to define the __call__ function with overloads for each valid combination of positional-only arguments, if not, the signature will have to start with *args and give up on type checking the optional, positional-only arguments.
Operators, as found in
bpy.ops.<submodule>, are actually classes, instances ofbpy.ops._BPyOpsSubModOp, which have functionspoll,idname,idname_pyandget_rna_typeand propertybl_options. (the real bpy.ops module containing the class is in scripts\modules\bpy\ops.py)Additionally, the current signature for these operators (as functions) is actually incorrect because the positional-only arguments,
override_context,execution_contextandundoare optional (though must be in the provided order), e.g.,override_contextcan be omitted when only providingexecution_contextorundo. The current function signature requires thatoverride_contextis provided if also providingexecution_contextorundo, which is incorrect.When rewriting ops as classes, it might be possible to define the
__call__function with overloads for each valid combination of positional-only arguments, if not, the signature will have to start with*argsand give up on type checking the optional, positional-only arguments.