[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