[Bf-python] Thought about IRC meeting and beyond

[Gilbert, Joseph T.]

Sorry for not being there. I got this from the meeting log:

1) We will experiment with documentation systems. In particular we will
try out splint, doxygen comments in source.
2) We will modify the API to use radians as the default instead of the
current degrees.

Some other meeting agenda items I would have like to see (and maybe you
can comment here):

1) The use of True/False over 1/0:
The api uses 1/0 for tp_getset or getter/setter in a number of places. I
believe that we should allow only True/False for Boolean attributes.

2)Constants should be defined in the Module as PyObjects and wrapped by
the code in constant.c:
The result should be individual constant object in the module such as:
Module.CONSTANT1, Module.CONSTANT2.
Constants should be named with module conventions to avoid import
conflicts. I was thinking Module.MDL_CONSTANT1. e.g.
Blender.Armature.ARM_LOCX, Blender.Mesh.MSH_LOCX.

3)Remove Types.c and place objects in their respective modules using
Py_TypeReady() and including the object as a PyObject to the Module
dictionary.

4)implement tp_new/tp_init:
This could be done for high-level objects atleast. Stuff like object,
mesh, armature, lattice. For subobjects like vert, bone, beztriple, etc
maybe factory functions would be better i.e. myObject.newSubObject(args)
instead of myObject.addSubObject(SubObject(args)) (which would be the
tp_init way)

5) finish implementing tp_getset

6) Module hierarchy:
NLA needs to be moved out of Armature? Also should we place subobjects
of Object as submodules of Object e.g. Blender.Object.Mesh?

7) GC:
Do we need to implement GC on our object types? I would say yes for the
mathutils types and possibly subobjects like Bone. Not sure about the
rest.

8) OOP interfaces:
Not sure if everyone understands what I'm getting at here so I'll
explain.
Imagine we have an attribute called Object.attribute that returns
multiple objects and can be set with multiple objects. 
[] = Object.attribute
Object.attribute = []
They way we handle this is the past is to return a new PyList or take a
PyList as an argument.

The problem here is that we can't really expose the list interface of
the object. E.g. Object.attribute.append(newItem) does NOT add the item
to the struct. It adds it to the new pylist we just returned.
We want the pyList as part of the object. The way to do this is of
course embed the pyObject * in the struct:
{
PyObject *list;
}BPy_myobject

Now we can return EXPP_incr_ret(self->list). This allows
Object.attribute.append(newItem) and the items ends up in our internal
list. However the problem here is that ANYTHING we append ends up in our
internal list. Therefore we need someway to restrict items being added
to our list.

I suggest therefore we have some subclassable type of list/dict that
checks the type of object being set/got. This object can be initialized
with what is allowable and be embedded in the object struct.

The purpose of this is to generate a more friendly and python interface
to our typeobjects. This is really needed when we deal with
object->flags internally. Being able to do something like:
myObject.mode.append(Module.MDL_CONSTANT) would be the goal. Where
MDL_CONSTANT is checked by the typeobject in .mode to see if it's
allowed.
There might be a different way of doing OOP interfaces like this but I
though that this would be the way to accomplish this.