[Bf-python] More Proposed API changes.

[Campbell Barton]

Im for having "blend" imported into Pythons main dict by default.

otherwise haveing Blender.blend, its not so bad but I dont like that the 
functionality is one more level away, just because mixing it with 
existing functionality looks a bit odd (whole api rewrite/coexist problem)

It sounds pettie but a large factor in the adoption of the new functions 
is how much typing is needed to access them - If their nested away 
people wont be as likely to use them.

"blend" - also makes sense on a syntax level because all the sub 
attributes are lowercase...

   blend.scenes.active - rolls off the fingers very nicely ;)
as opposed to old style...
   Blender.Scene.GetCurrent().getActiveObject()


So assume we agree "blend" imported by default is ok...

What else might go into blend?
willain suggested blend.config - to access stuff that is currently 
accessed by Blender.Get('...')

for a new API we may want to look at new API;s for non data related 
stuff like re-workings of the Window or Draw module. would these go in 
"blend" ? blend.gui for instance,  or is that too messy?






Willian Padovani Germano wrote:
> Campbell Barton wrote:
>  > Just we can do this whilst keeping the same files, 3 modified lines of
>  > code will do this.
>  >> 3) Move Blender.Main.* into Blender.*
>  >>   Willain suggested we discuss this on the list.
>  >>
>  >>   So there wouldbe Blender.scenes, Blender.meshes etc...
>  >>
>  >>   This would be ifdef'd in a way that it could be easily omitted from
>  >> next release if people arnt keen on having it there.
> 
> As Campbell mentions, this is something we should discuss.
> 
> Currently there's the new Blender.Main module, from which we can access 
> iterators for scenes, objects, meshes, etc. right from G.main, for those 
> familiar with Blender C internals.
> 
> "Main" doesn't seem like a good name to me. It makes perfect sense for 
> Blender devs, but possibly none for everyone else.
> 
> So we can:
> 
> 1) Put these iterators directly in the Blender module: Blender.scenes, 
> Blender.meshes, etc.
> 
> Handy, but what I grew to dislike is conceptual: scene, meshes, etc. are 
> data belonging to a .blend file (which, actually, is the current one in 
> memory), let's say, they don't belong to "Blender" itself. In practice, 
> we note that e.g. Blender.meshes simply changes if we load another 
> .blend file.
> 
> So having something like Blender.blend.meshes, etc. may be a better 
> idea, specially if we automatically add it to Python's main dictionary 
> upon starting Blender. Users could then simply type things like:
> 
> blend.meshes['Cube'].LocX = 10.0
> scene = blend.scenes.active
> print scene.name
> 
> And we may be able to find a nice way to extend this "blend" idea to 
> support other .blend files.
> 
> 2) Find a better name for this new module.
> 
> Data? Blend? blend, as suggested above?
> 
> 3) Other suggestions?
> 
> ??
> 
> As always, good to keep our basic guidelines in mind: we're adding 
> nicer, *alternative* ways to do things with BPy; solid Python API 
> design, simplicity and readability are good things, etc (you know).
> 


-- 
See MetaVR Visuals Used at the Combat Studies Institute
http://www.metavr.com/casestudies/baghdadviews.html

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