[Bf-python] Implementing bpy.classes

[Campbell Barton]

Willian Padovani Germano wrote:
> Hi Ken,
> 
> Ken Hughes wrote:
>> I was going to start adding the new constant handling code to the pyapi 
>> branch, but since constants are supposed to be available through the 
>> bpy.classes module, I need to start implementing some of that too (I 
>> guess).  But what does this module really contains?
>>
>> For example, assume we have bpy.classes.Object.  Is this just the BPy 
>> Object type?  I.e, if you write:
>>   print bpy.classes.Object
>> should it just say
>>   <type 'Blender Object'>
>>
>> Or is "Object" a new type of BPy container which for now has constants 
>> for that class, possibly constructors or other things later?
> 
>  From what I understand, bpy.classes will only include object types. So, 
> for Blender objects, it's only the bpy object defined in Object.c, not 
> the Blender.Object module functions and constants (that should be moved).

I had to re-read this 3 times to get it ;) - object can mean 4 things. 
blender object, PyObject, blender object module or blender PyObject 
object type.

Agree, its only for types and not for module functions, we still need to 
deciede where they go. Blender.Object.Duplicate() for instance.

> But we can / should take the chance to rework these objects, improving 
> the current API to get rid of inconsistencies (vars should start with 
> lowercase, angles should be in radians, etc.), deprecated methods, bad 
> interface (way to access, return values) and so on.
Been doing this, Camera, sceneRender and Materials are mostly done.

> I'd also like to organize things better, for example by collecting 
> related variables in "containers" instead of using prefixes.
> 
> Example: using object.dup.objects, object.dup.group, etc. instead of 
> object.DupObjects, object.DupGroup, ...
> 
> Maybe object.dyn[amics] or object.physics to group all rigid and soft 
> body and particle interaction vars: object.dyn.sb.mass, 
> object.dyn.rb.radius, objects.dyn.pi.type, etc.
> 
> IMO, the current list of variables is messy:
> http://www.blender.org/documentation/244PythonDoc/Object.Object-class.html
> 
> The actual names / grouping are up for discussion, of course, assuming 
> we choose to do this.

agree the existing API is inconsistent and needs to be rethought.

regarding your suggestion
Id prefer..
  * object.dynSbMass <- the syntax we'v been using.
  * object.dyn_sb_mass

having (object.dyn.sb.mass) - It introduces overhead in writing the API 
as well as running - "dyn" and "mass" need to be PyTypes that reference 
back to the object and make sure its not removed etc.... also slower 
calling these variables since whenever you call it- 3 pytypes need to be 
made.

It also dosnt document as well- since each type has its own subtyps- you 
mey need to click through 3 levels of docs to find teh variable your 
looking for.. rather then having all the object.dyn* settings setting 
together in a list. * (maybe it could be made to document it in one 
list. however this is not something we'v done so far)