[Bf-python] integrating lib iter types

Joseph Gilbert jgilbert at tigr.ORG
Tue Feb 27 17:40:01 CET 2007


The tradeoff is duplication of code in the codebase.  We have discussed  
"from __future__ import Blender" before. I don't think it a bad idea, but  
we need to increase the size of the codebase in blender to have separate C  
files for all this stuff.  If we want to do this its a major design change.

Otherwise, any new functionality should:
a) never break old functionality until we are ready to do so
b) deprecate the old functionality to allow users to switch to the new  
code.

"""A future statement is a directive to the compiler that a particular  
module should be compiled using syntax or m
On Tue, 27 Feb 2007 10:32:42 -0500, Campbell Barton <cbarton at metavr.com>  
wrote:

> 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
>>
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



More information about the Bf-python mailing list