[Bf-python] integrating lib iter types

[Campbell Barton]

duplicating the codebase isnt such a big deal, to start with we wont 
have many C files, and in general new style code isnt as heavy as the 
old code, See Metaball.c as an example.

Since it seems people would rather go with c) - I think we shouldn't 
worry too much about Blender.Object and Blender.objects coexisting

basically, dont compromise the new API because of existing keywords in 
the current API...


Joseph Gilbert wrote:
> 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
>>>
>>
>>
> 
> 
> 


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