[Bf-python] Object types as string

Willian Padovani Germano wgermano at superig.com.br
Wed Apr 4 19:09:31 CEST 2007


Stephen Swaney wrote:
> On Wed, Apr 04, 2007 at 03:13:42PM +1000, Campbell Barton wrote:
>> Hi, just wondering if were ok about ob.type's being a string..
>>
>> bpy.ipos.new('name', 'Material') # new material ipo
>> ob.type == 'Mesh'
> 
> Funny you should mention this.  I was just thinking about it the 
> other day.
> 
> As a general rule, we would like to get away from passing strings
> as arguments and use constants instead.

This is really something we should consider now carefully. There are 
advantages to both sides.

> We talked about constants a little bit at the last meeting.

And we still didn't agree on what will be done, so it's important to 
discuss this more, specifically: string constants vs. non string constants.

>>From a user perspective, constants have the advantage of being checked
> at 'compile' time rather than when the script is running.  The can
> also be handled programmatically rather then being hard coded as
> 'magic numbers'.
> 
>>From a C programming standpoint, constants can be used in case
> statements rather than the long if/else blocks you need with strings
> names.

Yes, Stephen covered the pros towards non string constants.

Now what would be good about string constants:

- If our constants (where possible, everywhere?) are strings, users can 
choose to either write the strings directly or the constants. Both ways 
are readable, strings are shorter: scene.objects.new('Empty') and we 
still have the constants so users can check all available types.

- Ken pointed months ago that he disliked how a user could write correct 
scripts using totally wrong constants, because internally their (int) 
values were the same. Something like lamp.type = Mesh.Modes.Twosided, 
for example. If we use strings instead of ints this can be prevented easily.

-- 
Willian



More information about the Bf-python mailing list