[Bf-python] Re: Mesh modes

[Joseph Gilbert]

Ken Hughes wrote:

>> Actually, the fix for this is either to (a) add more values in the 
>> range-checking for the mesh.mode setter or (b) not do any checking. 
>> Seeing as how this is a bitmask, I'm favoring right now not doign any 
>> checking since this interface will change in the API refactor.
>
If your going to check the input by value you have to perform a valid 
check on all the settable flags.

>>
>> Which brings up the question, what was the decision for handling 
>> bitmasks in the new API?  Neither of the wiki pages on the refactor 
>> seem to lists any decision.  Have none been made?
>
I believe we will go with boolean properties and drop flags and modes.

> Ken, not checking should be good :) IMHO (Faces too - causes similar 
> errors to mesh)

No. Not checking is not good. Setting inappropriate flag values on an 
object can cause internal problems.

> However flags can be very usefull esp when storing data for later use.....

Exactly. One perfect reason for not allowing users to set un-checked 
flag values.

> eg...
> faceModes = [f.mode for f in me.faces]

This reminds me of a python principle:
"If the implementation is hard to explain, it's a bad idea"

I agree though that getting rid of a returnable list (whether flag/mode 
etc) is a disadvantage in that it makes the API less pythonic imho.  You 
can't do:
for x in list:
instead you need to test a bunch of boolean values
if x.y and x.z and x.w and x.p and x.z:

However, building and settings lists is more complex when your talking 
about bitfields etc. then a simple boolean.  Go fish. :/