[Bf-python] Implementing bpy.classes

Willian Padovani Germano wgermano at superig.com.br
Wed Jun 27 06:30:20 CEST 2007


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).

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.

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.

-- 
Willian



More information about the Bf-python mailing list