[Bf-python] Re: tp_getset conversion update

[Ken Hughes]

Stephen Swaney wrote:
> On Thu, Sep 29, 2005 at 08:15:25AM -0700, Ken Hughes wrote:
> 
>>So "mistype" is a legacy attribute (in 2.37a) while "lin", "sqr", and 
>>"qua" are new attributes which will someday replace it.
> 
> The principle of buttons corresponding to attributes is correct.
> The problem in this instance comes from applying it blindly.
> 
> In World, mistype is an attribute.  Its values can be 'qua',
> 'lin', or 'sqr'.  In the UI, this is presented as a set of
> radio buttons.  Only one can be selected at a time.

Ok, "blindly" is not accurate.  The epydocs I wrote which accompanied 
the patch *clearly* state that these three attributes are (a) mutually 
exclusive and (b) cannot be "cleared", but can only be set (which 
implies clearing the others).  I thought about this a while before 
implementing it (or, at least I thought I thought about it).

Not taking offense, just saying thought DID go into this.

Let me also throw out a related situation which similarly needs a 
decision; the bitfield variables.  (NMesh.NFace.mode is a prime 
example).  There are 13 different bits in this mode; two are mutually 
exclusive (the "Halo" and "Billboard" buttons).  If a script writer 
wants to set/clear/test one bit in this field, they could use 
mesh.face[0].sharedVert for example.  But if they want to initialize the 
complete bitfield, they would have to have 12 separate statements (not 
13, because setting "Billboard" would clear "Halo").  A single 
"mesh.face[0].mode = ..." statement might be more appealing.  So from a 
"being user-friendly" standpoint, seems like the API should provide BOTH 
ways of setting the bitfield.

So what would we decide?  We do/don't want to povide both ways? 
Sometimes one way make more sense, at the expense of the API doing 
things inconsistently ("Why does Material API have set/clear for this 
bitfield, but NMesh doesn't have it for that bitfield?")?

> Note: Since the word 'mistype' does not appear in the UI,
> maybe we should call our attribute 'misttype' so it does not
> resemble the word for typing error.  Or perhaps 'falloff'
> would be even better since that more closely describes its
> use.

"mistType" would be more pythonesque.

Ken