[Bf-python] Checking where we are

[Ken Hughes]

Willian Padovani Germano wrote:
> Hi,
> 
> Ok, it was a long winter down here and I haven't been helping enough 
> with bpython and scripts, but I hope to be able to work more from now on.
> 
> It'd be worthwhile to discuss a little how the overhaul is going and 
> plan what we can and should do before the official 2.40. I've just read 
> the development notes in the wiki:
> http://mediawiki.blender.org/index.php/BlenderDev/BpyApiDiscussion
> 
> Probably we won't be able to define and perform all changes now. That 
> forces us to keep compatibility for 2.40, which is actually a good idea, 
> you all know. It's much better to break things at the beginning of 
> development, giving time for script authors to adapt, suggest other 
> changes, etc.
> 
> New functionality (specially new getsetters, of course) is ok imo, even 
> if the API changes later, but current scripts should work with 2.40 
> where possible. The changes in Mathutils were made before 2.40-alpha 1, 
> so people got 2 pre releases to get to know them, that's enough. 
> Armature/bones just has/had to be rewritten and will surely benefit from 
> that.

One thing I'm coming to appreciate (and might even more if I look really 
closely at the BPy code) is the "top-down approach" that Stephen has 
pointed out more than once to me.  I didn't realize that there are a few 
places where you can't do something to one piece of data unless you also 
know what other pieces of data link to it.  Three examples I've seen in 
the last month:
(a) mesh vertex data is actually stored in the object linked to the mesh
(b) some particle system calculations rely on the settings of the object
(c) something Johnny Matthews came across while working on the IPO 
drives interface (sorry, my brain dumped the details).

It seems cleaner to do
     ob.effect[0].getParticleLoc(time)
as opposed to
     Effect.getParticleLoc(obj,0,time)

or to do
     ob.data.addVertexGroup(name)
as opposed to
     Mesh.AddVertexGroup(ob,mesh,name)

I'm wondering if there are other places in the API where this problem 
exists that I haven't thought of, and if so it is a problem that should 
be tackled while we're looking at things?

Ken