[Bf-python] Proposed BPyAPI Additions.

[Joe Eagar]

Campbell Barton wrote:
>
>
> Ken Hughes wrote:
>> Campbell Barton wrote:
>>> Im not keen on this at the moment,
>>> having reset would only help in cases where users had the same PyObject
>>>
>>> # eternal loops like this would still be possible unless we store 
>>> some data in the Blender scene
>>> for ob in scn.objects:
>>>    scn.objects.new(ob.data)
>>>
>>> the way the iterator currently works is......
>>>
>>> iter is a BASE pointer, initialized as  NULL, if your loop on 
>>> objects it will to a Base.
>>> when your finished iterating its set back to NULL.
>>>
>>> if your loop over the objects and the PyTypes iter value is not 
>>> NULL,  then a copy of the scm.objects is returned with iter set to 
>>> NULL.
>>> Without this... the following would not work.
>>>
>>> obs = scn.objects
>>> for ob1 in obs:
>>>  for ob2 in obs:
>>>    print ob1, ob2
>>
>> I guess I see the problem you're talking about: there are two 
>> different iterators even though to the user there is only one 
>> sequence ("obs"). The internal loop is a different iterator PyObject.
>>
>> I'd vote for one of these two solutions:
>> (1) don't allow add or remove in iterators, period
>> (2) allow users to add or remove at their own risk, particularly 
>> remove().  Adding can cause and enless loop, removing may mean you 
>> crash (if you remove the object the iterator is pointing at).
>>
>> (1) seems a lot more safer, so if a user wants to add an object to 
>> the scene they should add to a list, 
Supporting .remove() would be as simple as making each iterator object
insert themselves into a list attached to the head objects sequence
object, so .remove could then loop through all iterators and change any
whose current value is the object being removed.

I'm not sure this is worth it, though.  might be better to just have a
system that raises an error if you try and call .add or .remove while
iterating though.

Joe