[Bf-python] naming conventions, some propositions, and some misc reflexions...

[Michel Selten]

On Thu, 2003-06-19 at 15:49, Jacques Guignot wrote:
> Some propositions :
> 
> 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)

Good!

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

yes!

> c) Intern and helper functions : no rule

Well, maybe as a guideline, let the functions start with a capital?
Or are we already doing differently? (I haven't checked all .c and .h
files).

> d) keywords for the "getattr" and "setattr" : use the names of the 
> fields in the corresponding C structure (they are generally well choosen)

Ok.

> e) in "getattr" and "setattr" : try to reuse the corresponding the 
> existing functions.
> 
> example :
> static PyObject *World_GetAttr (C_World *self, char *name)
> {
> if (strcmp (name, "name") == 0)return  World_getName (self);
>  
> counter example (sorry, Willian!) :
> if (strcmp(name, "name") == 0)
>     attr = PyString_FromString(self->camera->id.name+2);

Well, for the settattr I agree. But for the getattr I used the direct
way in Object.c.

> f) I think that the speed factor should be considered as not very 
> important. It is crucial for guys working on rendering or computation of 
> the image. Not for us, an intepreter is not very fast by nature.

True, but some scripts can become quite complex. So speed should be
taken into account. However, when speed results in code which is
difficult to maintain, I'd rather go for the more readable (and slower)
solution.

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

well, some return a PyObject as argument. For example the coordinates
can be a vector object.
I don't think we should put restrictions on return values. Use what
makes the most sense.

Great work Jacques! Keep up this kind of work. This can be used as input
for a writing Python modules document.

With regards,
	Michel