[Bf-python] Implementing bpy.classes

[Toni Alatalo]

On Wednesday 27 June 2007 10:43:47 Campbell Barton wrote:

(oh no me on this again!)

> >> 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?

i am used to constants being in classes, but have never seen a classes 
*module* before (apart from bpy meeting notes) .. i have not yet understood 
the reason for it, gotta dig up the notes more i guess. you all probably know 
that usually classes just are in the namespace they belong to, in many 
packages just flat at the top or in their respective module (e.g. 
subprocess.Popen)

then again, some systems have constants in a specific module, like 
pygame.locals (so you can do 'from pygame.locals import *' and pollute your 
namespace with only things like K_SPACE which is kinda nice). but i agree 
that putting constants to classes is probably better with Blender (many 
constants are type specific)
 
> >> For example, assume we have bpy.classes.Object.  Is this just the BPy
> >>   print bpy.classes.Object
> >>   <type 'Blender Object'>
> > 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).
> Agree, its only for types and not for module functions, we still need to
> deciede where they go. Blender.Object.Duplicate() for instance.

i'd think logically duplicating is not a module function, because it works on 
a specific object and is not in that sense a loose function. so i'd see it as 
an object-level instance method. but is this again the kind of refactoring we 
are not going to now? or why not move such 'module functions' to be instance 
methods, if they are to be moved anyway and if it is a logical place?

ob2 = ob1.duplicate()

granted, it seems that the current Object.Duplicate is quite a different 
beast, as it works on the existing selection etc. there are many ways to go, 
but one is putting such functions to the class too - just not as instance 
methods but as class methods ('static methods' in c++, java & c# -- not 
what 'classmethod' is in py). the idea there'd be that as it is a object 
level operation, it still is about Objects, just not any specific object. 
however often with Python just plain functions are used instead 
of 'static'/class methods, so i guess we could just have even:

bpy.duplicate(mesh=True, texture=True)

i guess there are arguments for putting them into some submodule too. i'd not 
encourage doing bpy.classes, bpy.functions etc. though unless it is really 
necessary -- often with python functions and classes are happily mixed in 
same namespaces and at least i have not found it a problem (e.g. 
subprocess.Popen is a class, subprocess.call is a function -- the doc at 
http://docs.python.org/lib/node529.html just links to 'convenience functions' 
on a separate doc page http://docs.python.org/lib/node530.html but the actual 
namespace is same).

> > I'd also like to organize things better, for example by collecting
> > related variables in "containers" instead of using prefixes.

+1

> > Example: using object.dup.objects, object.dup.group, etc. instead of
> > Maybe object.dyn[amics] or object.physics to group all rigid and soft
> > body and particle interaction vars: object.dyn.sb.mass,

i am not sure if sb needs to be under dyn, but when working a bit with 
Object.c i had the same conclusion that e.g. softbody would be better 
separated from there - perhaps with a new Softbody wrapper type for handling 
those settings, that an object either has or not (in which case the ref at 
ob.softbody would be null/None)

i am not convinced that Campbell's counterarguments stand against that idea ;)
e.g. having ob.softbody.mass

~Toni