[Bf-python] Re: tp_getset conversion update

Willian Padovani Germano wgermano at superig.com.br
Fri Sep 30 02:10:37 CEST 2005


Hi guys,

When we started using Blender's interface as our "razor" for the API, it 
was basically to define names. Although these can change, they tend to 
stabilize and are good enough to make a decision.

I believe that trying to favor button layout instead of good Python code 
is pushing this a little too far. Button layouts and types can change 
easily. For example, a set of buttons can be substituted by a menu, it's 
happened a few times already.

Going back to the sort of example I mentioned at the start of this 
rewrite (strs vs. const dicts), if we have a var that can take one of a 
group of values represented by words, doing it with a single var and a 
constant dict seems to be the cleanest / clearest approach, don't you think?

Example: object.myvar can be "strval1", "strval2", "strval3".

We use a constant dict:

Blender.Object.VALS = {STRVAL1: "strval1", STRVAL2: "strval2", STRVAL3: 
"strval3"}

and set values like this, using the const dict facilities:
object.myvar = VALS['STRVAL1']
or this:
object.myvar = VALS.STRVAL1

The same approach also works for bitfields nicely:

object.myflags = FLAGS.F1 | FLAGS.F2
object.myflags = FLAGS.F1 | FLAGS.F2
object.myflags &= ~FLAGS.F3
etc.

The issue with materials can probably be solved with extra code to check 
for incompatible mixes or just be clearly documented. It was done in a 
time where lots of modules were being added and we were always expecting 
important changes (in materials, in this case). Now we're used to (and 
quite happy with) the fact that Blender changes a lot and we should not 
postpone things unless clearly stated that code is bound to change soon 
(like is expected with vertex keys, for example).

-- 
Willian



More information about the Bf-python mailing list