[Bf-python] Proposed BPyAPI Additions.

[Ken Hughes]

Willian Padovani Germano wrote:
> Ken Hughes wrote:
> 
>> Regarding fixing Object.New() to protect against objects with no 
>> obdata, I can only see two solutions.
> 
> If we're confident the ob deallocator is always called, even if the 
> script fails (I can't test right now), then your solution to change type 
> to Empty could be done there, upon checking that type != Empty and 
> obdata = NULL, right? Another possibility is adding empty obdata of the 
> right type to the object, but it doesn't seem nice to leave an unlinked 
> object in Blender.
> 
> If an object is not linked to a scene and has obdata = NULL, isn't it 
> safe to assume that it was created by mistake via bpy and to get rid of 
> it in the bpy deallocator (again, if we're confident that it's always 
> called)?
> 

I've tested and if there is an error in the script (not a syntax error 
but during execution) it seems Object_dealloc() is called.  The problem 
with only handling the error there is that it's possible for a object 
with no obdata to be created and accessed before Object_decalloc() is 
called.  For example this three-line script:

from Blender import *
x1 = Object.New('Curve')
x2 = Object.New('Curve')

If we try to delete the objects in Object_dealloc() using 
free_libblock_us() -- the same code used when deleting an object in the 
UI -- the deallocator for x1 (or x2) when called will eventually 
encounter the other object prior to its deletion and cause an error.  So 
changing the object we're deleting doesn't help for the object which has 
yet to be delete.

So the issue I encountered was that even if we do delete one invalid 
object, there may be other invalid objects which will cause problems 
before we can delete them.  Without changing the non-python code to 
ignore when this might happen, the only way to avoid this is to make 
sure that all objects are valid non-obdata objects (i.e., Emptys) until 
they are defined.

Ken