[Bf-python] Iterators in blender data

[Campbell Barton]

Discussed direct iterator access with with broken, Briggs and joeedh
scene as an iterator as for eg.
for ob in scn: ...

rather then for ob in scn.objects

All agree'd that...
1) unlike blenders inner workings - a scene dosnt just store objects.
2) inconsistant with other modules where an iterator isnt a part of the 
python representation.
3) scn.add() scn.remove() - should be kept as a part of scn.objects

A scene is not just an object storage.
making it access objects directly perpetuates this misunderstanding and 
while convenient, and perhaps nice for new users.
fast access can easerly be done.
  obs= scn.objects

Juts like render alredy is.
  rnd= scn.getRenderingContext()

- Cam





Campbell Barton wrote:
> When making the metaballs api I added an iterator to the metaball type 
> called .elements
>
> mb= Metaball.Get('someMb')
> for ml in mb.elements:
>  print ml.co
>  print ml.type
>  print ml.radius
>
> new_el= mb.elements.add()
>
> But this got me thinking. just as we may not use scn.objects.add() in 
> favor of scn.add()
>
> why not make the metaball type an iterator its self?
>
> for ml in mb: print mb
> or len(mb)
>
> The only bad thing about this is that you cant assign a list.
>
> Since apart of my plans are to make the API's consistant. what about 
> doing the same thing for groups.
>
> gp= Group.Get('Group')
> for ob in gp.objects:
>  print ob.name
>
> could be....
> for ob in gp:
> ....
>
> In this case, having 'objects' is usefull because you can assign 
> objects to it.
> gp.objects = [ob1, ob2, ob3]
>
> if objects was removed, a solution might be a 2 step process.
>
> gp.clear()
> gp.extend([ob1, ob2, ob3])
>
>
> The only reason not to do this is for data that may have more then 1 
> type of iterable data. - like mesh for eg.
> but for Metaballs, Groups, Modifiers and Scenes it should be ok.
> (Im unsure about scenes because they contain a fair bit of data, but 
> objects are the most commonly used iterables they contain so I guess 
> its ok)
>
> The one bad thing is it makes the code a bit less readable especialy 
> if you done have good variable names,
> for E in M: ...
> for O in g: ...
>
> for E in M.elements: ...
> for O in g.objects: ...
>
> - Cam
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>


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