[Bf-python] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender  branches/pyapi_devel/source/ blender/python/api2_2x: * Added Constants to Mesh
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
>>>> 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
>>> 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".
>>> (PS: description of implementation:
>> 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