[Bf-python] Python Meeting (after sunday meeting)

Campbell Barton cbarton at metavr.com
Thu Jun 14 18:06:49 CEST 2007


Hi, been looking at the existing api and making some changes..
Its aparent that I cant go too much further until some decisions are 
made, so Id like to have a meeting regarding the Python api.

Some topics...

1) Do we even want a new API for blender 2.5?

if so, to what extent should it change from the existine one?
- Id suggest remove deprecated get/set's and rewrite some parts at a 
minimum (Lattice, shapekeys, some parts of the armature API are not in 
keeping with the rest of Blender)

- But Id like to propose we keep the existing code but scrap Blender.* 
and NMesh, better organize the layout using bpy.* - new way to use 
constants, layers, and a fix up other areas.


2) Is the pointer problem something we can fix for 2.5?
Ton is against adding a PyObject pointer to the ID struct (or having 
blender data reference back to PyObjects at all)

So the options are
a) not worry about it.
b) workaround the problem where possible
c) have the python API keep track of its PyObjects and have blender tell 
Python API when data is removed (ton suggested this)

Bad pointers are not a common problem practically but when a script 
makes them, it can take hours to work out where the source of the 
problem is. and Id prefer not chance scripters with possibly memory 
corruption bugs. - So fixing this problem is important IMHO.

If it cant be solved we can deciede to make the API in a way that dosnt 
end up causing these problems too much.

so scene.render.imageType
could be scene.renderImageType
that way the chance of removing the scene and keeping render PyObject 
with an invalid pointer wont happen. Putting many variables in scene 
directly is ok if they are prefixed with render for instance, so they 
are not mixed in with timeline, layers etc.


3) Constants- been discussed enough but need to decide so they can be 
implimented.

4) New/Old API's coexisting? - will need to work this out well before 
release.



More information about the Bf-python mailing list