I sometimes run into annoying API design(but assumingly not a bug).
Why not share them here?
Right here, perhaps?
You can get real-time discussion on freenode IRC in the #blenderpython or #blendercoders channels, but that depends on someone being around when you are.
If it’s a feature request they should go onto rightclickselect if you’re planning on working on it your self, this place will be just fine.
i think the whole API stability concept went out the window when Beta landed anyway. Every time I update nightly I feel like I’m fixing small api change bugs in my addon
Then, I’ll make this thread a place for python API papercuts for now.
1 Like
I would like to have a immutable and unique Identifier for each ID(data-block).
Currently, it is almost impossible to keep track of a specific ID via python.
The best we can manage is using the name of the ID, which is mutable and may be automatically renamed as blah.001.
4 Likes
override context is a total mess.
For example, it exposes the obejct base which should be hidden internally.
Can’t add new spline curve variables (or color ramps) so you can use the node widgets with your own parameters
Nice for the Python API to get some attention 
I’ll add tasks to Python & Add-ons Module where possible.
2 Likes
Agree, however this is more a general issue with how operators access the context and the kinds of context members that exist.
It’s quite opaque from a Python developers stand-point, also - the context members used may change when an operators internal logic is updated.
(think this isn’t a paper-cut, more an issue with operators not being design with Python as their primary use-case).
This papercut is about the API reference. Specifically the UILayout page.
Is there anything that could be done to not have all the icons listed multiple times? Sometimes I want to see what UI options I have, but the endless scrolling makes it a bit painful…
2 Likes
Here’s a couple regarding BVHTree:
-
BVHTree.FromBMesh, BVH.FromPolygons and BVHTree.FromObject functions need a “world_matrix” property that will allow performant creation of a BVHTree in world space. Dancing around the depsgraph to get transformed geometry in any reasonable amount of time is tedious when it could and should be done under the hood by default.
-
BVHTree.overlap would benefit from a “volumetric” property that returns any index that is inside the overlapping volume of the two bvh trees. Trying to use a BVH tree cube created from a list of verts and I only get the “outline” where the “selection” cube intersected the target bvh tree. less than ideal
While we’re at it, BMesh.from_edit_mesh/from_object/from_mesh could also use a world_matrix property. The current method of bmesh.ops.transform to matrix_world, and then transform back to matrix_world.inverted() when you’re done is fine and all, but it just seems… wrong? if you could inform bmesh that you are making these changes in world space, but dont’ actually want to transform the mesh that would be a lot cleaner.
as a complete side note gripe- am I the only one who thinks it’s weird that BMesh uses PEAR/underscores for its constructors but BVHTree uses PascalCase? 
Edit: Another quick BMesh related one since I’m working on something similar right now. Again, this is more for dense geometry since you won’t notice much of a speed improvement for low res geo:
A couple of new bmesh.ops functions speed up selection-related operations
- get_selection (pass in a bmtype for the elements you want and get a list back with all of the selected indices)
- set_selection (pass in a list of indices and a bmtype and set the selection)
if set_selection gets None as a parameter, everything is deselected for that element type. this would be HUGE for me personally- because every time I need to deselect geometry I have to loop through the entire bmesh and set every element.select to False for the element type I care about. we’re talking 300-400ms on a 200k vert mesh. It may not seem like much but there’s a huge hitch
There’s currently no warning or anything in Blender 2.79 to protect against people running addons designed for 2.80. Obviously nothing much can be done about that in 2.79 now, but going forward it might be good to have a warning when enabling an addon that targets an earlier or later Blender version. This is an area where moving to a semver version number system would be useful, but that’s a whole other discussion.
I’m not sure if this qualifies as a papercut per se, but I wish we had more callbacks/event handlers to subscribe to. There are lots of things that happen in Blender that, if we could add handlers to, could create some very new and interesting addons.
As an example- I really wish there was an event handler for bmesh updates. If I have a modal tool that allows pass-through behavior but modifies the bmesh on its own, I have no idea if the user has fired off a hotkey operator that modifies the mesh (IE: bevel/extrude) so my bmesh data either needs to be constantly rebuilt, or it’s potentially out of date and unreliable. Another useful one would be before/after an operator gets fired. You can currently do this by constantly monitoring wm.operators, but it’s super hacky.
the new depsgraph handlers are a LOT more useful than the old scene update handlers, but I think we could get some really interesting addons out of more event handlers. As a pipe dream- it would also be nice for addon devs to be able to write their own handlers and subscribe to them. Imagine a world where TeamC and Machin3 could write interconnected systems for their addons and other addon devs could subscribe to their handlers and write custom functionality. Limitless possibilities!
bpy.app.handlers.bmesh_update_pre
bpy.app.handlers.bmesh_update_post
bpy.app.handlers.operator_pre
bpy.app.handlers.operator_post
pretty please! 
3 Likes
- change modifer position in stack without bpy ops
- booleans directly in bmesh
- joining objects directly in bmesh (joining bmeshes?)
- ability to use bmesh.update_edit_mesh() with a bmesh object argument
- this would avoid having to switch out to object mode, use bm.to_mesh() and go back into edit mode again
5 Likes
- Accessing Gizmos transformation matrix with Python (for move/rotate/scale tools for example). As far as I know there is no way of doing that currently.
Its been suggested I post this here. Already made the feature request but was wondering if anyone would find it helpful to have the edit-normal transformation vector available through the bpy module.
Yes, please, please…
and viewport matrix change (no camera) pre / post handler for undo/redo viewport addons.
I hope API support hieralchical list, for custom ID properties
Eg, I can add custom ID props for Context armature object (ob) by python, then make slider in UI panell. (they will drive shape keys, or bones transform)
ob[‘expression1’] = 0.00, ob[‘pose1’] = 0.00, obj[‘pose2’] = 0.00 , ob[‘expression2’] = 0.00
But I hope to group them as expression, pose, shape morph, etc.
If I can use list for id properties, I can add new custom prop with group. then easy access props with use group. Though I do not need 3D list, but hope 2D list for custom ID prop.
ob[‘group1’][‘prop1’] = 0.00 , ob[‘group1’][‘prop2’] =0.00 etc…