# What do new bpy class naming conventions in Blender 2.80 actually mean?

What are the new class naming conventions in Blender's 2.80 Python API for add-ons?

It says here:

This constraint applies to the bl_idname of each class (or the class name which uses it if no bl_idname is defined in the class).

These are: UPPER_CASE_{SEPARATOR}_mixed_case, in the case of a menu the regular expression is:

[A-Z][A-Z0-9_]*_MT_[A-Za-z0-9_]+

The separator for each class is listed below:

• Header -> _HT_
• Menu -> _MT_
• Operator -> _OT_
• Panel -> _PT_
• UIList -> _UL_

Valid Examples:

• OBJECT_OT_fancy_tool
• SOME_HEADER_HT_my_header
• PANEL123_PT_myPanel (lower case is preferred but mixed case is supported).

At the time of writing this, names that don't conform to this convention will produce a warning on startup. Eventually we will make this into an error, eg:

Warning: 'Oscurart Files Tools' doesn't contain '_PT_' with prefix & suffix
Warning: 'Oscurart Overrides' doesn't contain '_PT_' with prefix & suffix
Warning: 'Oscurart Animation Tools' doesn't contain '_PT_' with prefix & suffix

So this might mean that the bl_idname should actually be something like:

"object.MY_ADDON_OT_some_object_operator"

It still requires a '.' to be there so object.OBJECT_OT_something_something does not seem to make much sense to me. Does this actually apply to bl_idname? Could someone explain in more detail the idea behind this and how these conventions should be followed in practice?

• Good question. I thought you only add the "." when accessing the name, not when assigning. – ACopeLan Dec 11 '18 at 7:23

# It seems bl_idname of operators is an exception to this new convention

Looking through Python scripts that come with Blender 2.80 I can see that the convention is followed in bl_idname and class name as described with:

• headers( _HT_ )
• menus( _MT_ )
• panels ( _PT_ )
• UI lists ( _UL_ )

but not with operators since that is not possible. Operators sometimes follow this convention in their class names, but never in bl_idname, where they follow the usual categorization with the dot, like bl_idname = "object.randomize_transform".

That was the confusing part to me since OBJECT_OT_fancy_tool was given as an example without clarification and it would definitely not work as a bl_idname for an operator.

• I think what they refer to with bl_idname is the class name. If you go to the Python console in Blender, and run bpy.ops.object.vertex_group_add.idname(), the result will be OBJECT_OT_vertex_group_add. It's definitely something that needs work in the documentation. But for any operator, the convention is to use the structure from the bl_idname in the class name. Like MESH_OT_myop for something that has mesh.myop as bl_idname, OBJECT_OT_myop for object.myop bl_idname and so on... – aliasguru Dec 11 '18 at 8:25
• The bl_idname from an operator can by the way be retrieved using bpy.ops.object.vertex_group_add.idname_py() – aliasguru Dec 11 '18 at 8:26
• Also worth mentioning that the class name convention has been there since 2.61 at least. I remember Sebastian Koenig mentioning it in a tutorial series of his. The change with 2.80 now is that you are forced to follow it. – aliasguru Dec 11 '18 at 8:30
• They seem to refer to bl_idname with bl_idname. bl_idnames are following the convention as well as class names for headers, menus, panels and UI lists. It is also more serious with 2.80 since not following that will produce a warning now and it is going to become an error in the future. That's why I am so interested in this. I would not care otherwise. – Martin Z Dec 11 '18 at 8:47
• @aliasguru I have the feeling it has been recommended practice since 2.5. – batFINGER Dec 12 '18 at 5:40