[Bf-python] Methods that require object pointers

Gilbert, Joseph T. jgilbert at tigr.ORG
Tue Dec 20 19:37:05 CET 2005


This is something for the devs in particular and I'd like to throw this
out there:

As you know there are a number of methods internal to blender that take
a 'Object*' pointer.  E.g. where_is_pose(Object* object). We don't carry
these pointers inside our python classes for whatever reason. There
comes a time when we need to call an internal method that takes an
Object*. What's the call?

I see a few options here:
1 - We embed the pointer into the python class and all it's subclasses
that require it. i.e. we add a Object* pointer to every python class
that is a subobject of Object.
2 - We make the user call the method with a PyObject object argument.
Such as mySubObject.method_that_calls_internals(myArgs, myObject)
3 - We loop the ID structs to get a matching Object pointer. E.g.
For (obj = G.main->objects.first; obj; obj = obj->next) ....
If (mydata == obj->data)....
4 - We ask ton to recode his work.
5 - We put all these methods as a submethod of Object.

There may be another option or so I overlooked.

Issues:
1 - If we embed the pointer this data may go out of scope and could
potentially cause bpy to crash if an address is called with free'd data.
Also switching links among object would be painful.
2 - If we make the user pass a pyobject wrapper some methods might look
a little funky. The user will be asking 'why am I passing an object
here?' Another issue here is that we must somehow do a test of obj->data
etc. 
3 - If we loop ID structs this could be a major slowdown when this
method is called recursively.
4 - If we ask the other devs to recode - this may or may not happen for
technical reasons, as well as time constraints, implementation concerns,
etc. etc. 
5 - If we add all methods that require an object * pointer internally
the pyobject will become a dumping ground for every odds and ends
methods that internally required an object pointer. Most of these
methods would be more appropriate in a submodule.

Based on the above it seems to me that the best way to deal with this
issue when it arises is that we force the script writer to pass a
PyObject along with this method and swallow the fact we have to test the
object->data pointer.

What's the consensus?



More information about the Bf-python mailing list