[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
cbarton at metavr.com
Tue Jul 17 15:59:08 CEST 2007
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 alredy has its own liikups 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
More information about the Bf-python
mailing list