[Bf-python] Proposed BPyAPI Additions.

Campbell Barton cbarton at metavr.com
Sat Dec 16 00:21:16 CET 2006


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 obs:
  for ob2 in obs:
    print ob1, ob2

About the order of  objects, in blender there is currently no logical 
order imposed, which is why I made scn.objects follor pythons set() 
implimentation.
practically there is some order and we can choose where objects are 
added. but its not somthing we want the scripter to rely on because 
theres talk of it changing (alphabetically sorted I think).

If you iterate and then breake out of the list.. iterating again will 
start at the start is it should. - By returning a new iterator PyObject.


I think its fair to say-
"Dont add objects as you loop over them"

- If you want t odo that just do

for ob in list(scn.objects):
  ...

- Cam


Willian Padovani Germano wrote:
> Food for thought:
>
> Maybe forcing users to reset the iterator (of course if it's not at 
> its start anymore) before being able to add or remove itens is not a 
> bad option.
>
> After all, if you iterate a little, then break out of the loop and add 
> or remove something, what is the state of the list? What you removed 
> has already been looped over or not? Only by keeping some control and 
> doing some testing the user would know.
>
> There's useful info at the very end here: 
> http://www.python.org/doc/2.2.3/whatsnew/node4.html
>
> Here's what is written there:
>
> "Note that you can only go forward in an iterator; there's no way to 
> get the previous element, reset the iterator, or make a copy of it. An 
> iterator object could provide such additional capabilities, but the 
> iterator protocol only requires a next() method."
>
> So we could add .reset() methods (e.g. scene.objects.reset()) to let 
> users rewind an iterator to its beginning, for the rare cases where it 
> would be needed. This would let us forbid adding/removing inside loops.
>
> Opinions?
>
> Campbell Barton wrote:
>> Looks like its keeping a count with
>>
>> mp->ma_used;
>>
>> If this changes in size then it raises an error, to do this properly 
>> we'll probably need to store some data in the scene, though using the 
>> pyType may be weak but good enough.
>>
>> Willian Padovani Germano wrote:
>>> Hi, Campbell
>>>
>>> Python dictionaries do it, so it's a good place to start looking for 
>>> ideas. I just saw the error msg here (function dictiter_iternextkey ) :
>>>
>>> http://svn.python.org/view/python/trunk/Objects/dictobject.c?rev=52550&view=markup 
>>>
>>>
>>> Will spend some time on this weekend, to learn more about the 
>>> possibilities.
>>>
>>> Campbell Barton wrote:
>>>> Hey Willian,
>>>> I dont think we can stop people from adding new objects while 
>>>> iterating.
>>>>
>>>> I thaught doing somthing like only allowing to add a new object 
>>>> when the the pypypes  "iter" value is NULL
>>>> would be ok but  it wont work if you break early.
>>>>  
>>>> I think the only way it can be done is to use a refcounter on the 
>>>> scene that lets python know how many scn.objects  there are 
>>>> iterating (can increment on getIter), and only if its 0, let the 
>>>> user add objects.
>>>>
>>>> All up I dont think its the biggest of our problems, but interested 
>>>> to see if theres another way to do this.
>>>
>>> It's important but probably not a show-stopper. If we can't find a 
>>> good way now, it can be done later, as long as the docs clearly tell 
>>> users not to add/remove objects inside loops.
>


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