2
$\begingroup$

Simple addon template :

import bpy

bl_info = {
    "name": "test",
    "author": "me",
    "version": (1, 0),
    "blender" : (2, 80, 0),
    "location": "",
    "warning": "",
    "wiki_url": "",
    "tracker_url": "",
    "category": ""
}

class OBJECT_OT_CustomOp(bpy.types.Operator):
    """Tooltip"""
    bl_idname = "object.test"
    bl_label = "test"

    def execute(self, context):
        
        None
        
        return {'FINISHED'}

addon_keymaps = []

def register():
    bpy.utils.register_class(OBJECT_OT_CustomOp)

def unregister():
    bpy.utils.unregister_class(OBJECT_OT_CustomOp)

if __name__ == "__main__":
    register()

My question is about that class name (-> OBECT_OT_CustomOp). I just want to know : Whatever name it is , can i really re-use it for other customop/addon ? since i've tried to use that same class name for different op and it doesn't conflict. Everything works fine, because that customop is unregistered when i exit the tool ? But will it break at some point ?

$\endgroup$
5
  • $\begingroup$ Hello, why do you want to re-use the name ? Do you enable the add-on in the preferences or do you run it from a scripting editor ? $\endgroup$
    – Gorgious
    Commented Nov 24, 2020 at 7:42
  • $\begingroup$ From the add-on, install and enable in preference , and it will add item in menu to run a function. Since i think everytime the function is done, it will unregister the class, so then i can reuse it without conflict. Because i've done it (use for 2 different addon) and there's no conflict or error. There's no purpose of reusing it, It's jut i'm curious because it works. $\endgroup$
    – andio
    Commented Nov 24, 2020 at 8:06
  • $\begingroup$ "every time the function is done, it will unregister the class"? It will only invoke unregister when user intentionally disable that addon. (Or invoke that method directly) $\endgroup$
    – HikariTW
    Commented Nov 24, 2020 at 8:32
  • $\begingroup$ sorry , i thought it will be unregistered when i'm done with the function. But if it's unregistered when i disable in preference, then how it come ? the 2 different addons (which share same class name) are ON and they still working without poblem ? Hoe come ? $\endgroup$
    – andio
    Commented Nov 24, 2020 at 9:33
  • $\begingroup$ The real case is : i duplicate my addon , modify it as another addon and forgot to change the classname of the 2nd (duplicated) addons, so they use the same classname. I found out later that they share the same classname, but i'm confused because so far , they just works and no conflict. I'm just confused and curious why this happen . $\endgroup$
    – andio
    Commented Nov 24, 2020 at 9:40

2 Answers 2

3
$\begingroup$

Same class name is not an issue.

when a register-able class is registered it is added to bpy.types with a name generated from the bl_idname.

eg

class Foo(bpy.types.Operator):
    bl_idname = "object.test"

if succesfully registered will be known to blender as the class

bpy.types.OBJECT_OT_test

or similarly after running question code in text editor (__main__ thread) The OT stands for "Operator Type", similarly PT and MT are Panels and Menus respectively.

>>> bpy.types.OBJECT_OT_test
<class '__main__.OBJECT_OT_CustomOp'>

>>> bpy.ops.object.test.idname()
'OBJECT_OT_test'

>>> bpy.ops.object.test.idname_py()
'object.test'

Can also import it as a module from text block, and run the register method. This is, IMO, a better way to test simple addon code in blender as it gives the option to unregister, since the classes are no longer "lost" in the main thread. Find Link

>>> myaddon = D.texts['Text'].as_module()
>>> myaddon.register()
>>> bpy.types.OBJECT_OT_test
<class 'Text.OBJECT_OT_CustomOp'>

So has now re-registered the operator, this time belonging to the "Text" module. Having a variable the same name in the scope of its own module is no issue. Having another matching bl_idname will overwrite the one registered previously.

Would either stick to naming convention and

class OBJECT_OT_test(...):
    bl_idname = "object.test"

or not at all

class TestOperator(...):
    bl_idname = "object.test"

whereas feel question's OBJECT_OT_CustomOp is some hickly-dy pickle-dy in-between sort or arrangement.

$\endgroup$
0
$\begingroup$

Got a quick test over different situation:

  1. register same class name same bl_idname:

    Blender will overwrite existing operator mapping (bl_idname → initiate same python class)

  2. register different class name with same bl_idname:

    Still, Blender overwrites existing operator due to bl_idname overwritten, this cause all operators registered before using same bl_idname replaced by new one(there should be only one, of course)

  3. register same class name with different bl_idname:

    Blender does not complain about duplicate class name since it works only on bl_idname, the new operator with same class name will work concurrently with the previous one. Both can be access by different bl_idname.

Since the test is done in text editor, each run has it's own scope, local name will not affect each other. So you are free to "reuse name".

On the other hand, the register() will map a bl_idname to an operator class, use that class object to do operation when user call an operator. IIRC the object is registered in separated place (RNA meta) and it shouldn't conflict with name either you assign a new operator to original operator.

e.g.

#  Code:
import io_mesh_uv_layout  # UV layout exporter ops
io_mesh_uv_layout = OBJECT_OT_add_object  # random ops from template

# Execute UV layout exporter → Original UV export operator

Not sure if there is any mistake in this discussion

$\endgroup$
3
  • 1
    $\begingroup$ The real case is : i duplicate my addon , modify it as another addon and forgot to change the classname of the 2nd (duplicated) addons, so they use the same classname. I found out later that they share the same classname, but i'm confused because so far , they just works and no conflict. I'm just confused and curious why this happen $\endgroup$
    – andio
    Commented Nov 24, 2020 at 9:49
  • $\begingroup$ how should they break? Unless they share the same python namespace “scope”, same name between two add-on will be fine without knowing they are twins. The register is kind of dictionary key in, although name are same, but the id of python class is different, hence both can work $\endgroup$
    – HikariTW
    Commented Nov 24, 2020 at 10:38
  • $\begingroup$ register() take care of bl_idname inside the given class attribute. It then set an index for that idname with that class object. something like bl_idnames: dict[bl_idname] = OT_classname_object. So if the id name doesn’t conflict,this dictionary works great even the name inside it is same(but they are not in general). But as you mention, now I am curious about the class itself: Is the class instance create every time when running an ops? Or there is only one operators per scene(or context). I am afraid I just talk all bullshit about it and misleading readers of this answer $\endgroup$
    – HikariTW
    Commented Nov 24, 2020 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .