[Bf-python] integrating lib iter types

Campbell Barton cbarton at metavr.com
Tue Feb 27 16:32:42 CET 2007


Thinking this over, looks like its too messy to mix in with the current 
code then I think we should define a new "Blender" - so we can do a 
"Blender_Future" module and just maintain the existing API..

Moving to a new API is fine, but at some point you either end up with a 
lot of duplicate functionality or have to start removing old functions...

It seems like it will be less trouble to start with a new module.. then 
we can experement more and not worry about breaking the existing stuff.

Campbell Barton wrote:
> Joe Eagar wrote:
>> Ed Blake wrote:
>>> Maybe put the __iter__ method in the submodules?
>>>
>>> Ex.
>>> obj = Blender.Object.New('Empty', 'test')
>>> # or
>>> for obj in Blender.Object:print obj.name
>>>
>>> Modules are (seem like?) just objects, no reason (in theory) they 
>>> can't have
>>> an __iter__ method right?
>>>
>>>   
>> I don't think you can add an iteration protocol handler to a module.  
>> The point of the new iterators is basically to replace the modules 
>> with iterator objects, though so it's really the same thing (just 
>> different names).
>>
>> Joe
> even if we could do
> 
> for ob in Blender.Objects:
> ...
> 
> or
> ob = Blender.Objects['myOb']
> 
> It seems cludgy to make these types mix the new and the old. on the C side.
> 
> Also mixes up the new API with the old one.. so if we want to drop the 
> old API and the move would be more messy..
> 
> 
> Thinking about it Id like to have Blender.objects, scenes etc.
> 
> Then we can also add some new types like Blender.config suggested by 
> Willain, to replace Blender.Get/Set
> 
> 
> 


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241



More information about the Bf-python mailing list