[Bf-python] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [11293] branches/pyapi_devel/source/ blender/python/api2_2x: * Added Constants to Mesh

[Campbell Barton]

Ken Hughes wrote:
> Campbell Barton wrote:
>> Ken Hughes wrote:
>>   
>>> Campbell Barton wrote:
>>>     
>>>> Revision: 11293
>>>>           http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=11293
>>>> Author:   campbellbarton
>>>> Date:     2007-07-16 23:20:52 +0200 (Mon, 16 Jul 2007)
>>>>
>>>> Log Message:
>>>> -----------
>>>> * added utility functions for new constants Const_FromPyObject to make getting the const from a PyObject easier.
>>>>  (also changed a few things you may want to look Ken)
>>>>   
>>>>       
>>> May want to discuss this further before we make a lot of changes.  One 
>>> thing which came up during the discussion
>>> about constants was being able to use strings instead of actual constant 
>>> objects:
>>>
>>> ob.drawType = "BOUNDBOX"
>>>
>>> Turns out this was not hard to implement so I wrote an API function 
>>> PyConst_Lookup() which searched for a match and
>>> returned the constant's value.  But since we didn't actually agree to 
>>> support this in the API, maybe we should decide whether
>>> we want this or not.  Again, from a coding standpoint it's not a big 
>>> issue, it's just a "standards issue".
>>>
>>> Ken
>>>
>>> (PS: description of implementation:
>>> http://wiki.blender.org/index.php/BlenderDev/Bitfields#Use_of_Strings_in_Place_of_Constants 
>>> )
>>>     
>> As long as all blenders functions use Const_FromPyObject - we can 
>> keep/remove string support without touching every file that uses constants.
>>
>>   
> Good point.
> 
>> Its nice how you can set a constant without all the prefix's of constants
>>   
> My tests showed that the most efficient way (i.e., fastest scripts)  to 
> use constants was to assign the const to a local variable:
> 
> cnst = Object.DrawTypes.BOUNDBOX
> for o in scn.active.objects:
>     o.drawType = cnst
> 
> 
> So if typing is a pain, it's actually best to put the constants into 
> short variable name and use that.
> 
>> but bad how there is 2 ways to set a constant and the string isnt 
>> associated with anything also a teeny bit bad how it does a lookup on 
>> the constant tho if you compare with all the lookups going on in pythons 
>> internals its no big deal.
>>   
> 
> Yeah, the main downside is the lookup, which can be slow if there should 
> be a long list of constants.  That could be mitigated by requiring that 
> constants be stored in alphabetical order, but the overhead for 
> something like a binary search would be significant for short lists.
> 
> 
>> - Cam

Unless anyone feels strongly about this I vote we leave is as.

The lookups are no big deal, python already has its own lookups when 
doing foo.bar.THING - so a lookup on a string is ok IMHO and in most 
cases there will be average of 5 of so items, max 20-30

One issue is how to store these in a file, say a script wants to store 
an objects drawtype in a way that can be read back, and applied. I think 
this should be possible. which is one reason to keep strings.

An alternative could be to have str and repr functions so scripts could 
do...
s = str(bpy.types.Foo.CONST)
.....
const = eval(s)

But that would mean consts would need to have a way to give their full 
path and at the moment thats not trivial.

- Cam