[Bf-python] naming conventions : synthesis of the discussion.

[Jacques Guignot]

Hi!

Here is a short resume of the discussion about naming conventions 
(Jordi, if you want to add something, it is the moment!)



a) The C functions are prefixed with the module name, and underscore
for readability, followed by "get" or "set" and the name of the field 
(or group of fields)

examples :
static PyObject *World_getName(C_World *self)
static PyObject *World_setName(C_World *self, PyObject *args)

b) The corresponding python functions are the same, without the module 
name :
example :
getName, setName

c) Intern and helper functions : no rule

(Michel) Well, maybe as a guideline, let the functions start with a capital?
(Willian) If there was another function in Blender with this name, I haven't
tested what would happen.
(I) probably nothing. And gdb can point at a function using the syntax
break filename:functionname (or something like this)



d) keywords for the "getattr" and "setattr" : use the names of
 the fields in the corresponding C structure (they are generally well 
choosen)
(Michel)  Michel does not follow this in Object.c
(Willian)  In getattr ...



e) in "getattr" and "setattr" : try to reuse the corresponding the 
existing functions.
(M ant W) : hmmm...

g) Arguments : for compound objects (coordinates or color values for
instance) the "get" functions will return a list.
The "set" functions will accept a list as argument.

(Michel) I don't think we should put restrictions on return values. Use what
makes the most sense.
(Willian) OK for new modules. Old ones must keep compatibility.



Prefixes :
(Willian) Substitute EXPP_ for BPY_ before final integration.
(Willian) Substitute C_ for BPy_ .
(Willian) For the M_ one, Leave it as M_ ?


(Willian)
In every module, we follow this syntax :

M_Object_Get()
Object_getData()
Object_dealloc()
Object_CreatePyObject()
Object_Init()

(Willian)
potential clash between Blender types and Python types :
fix : change the names of the objects to BPy_XXX