[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