[Bf-python] More Proposed API changes.

[Ken Hughes]

Irregardless of which way we decide to do these changes, I really want 
to see them documented somewhere before we commit to them (and I don't 
mean as in "cvs commit"; changes can be put into the source tree as we 
go along).  I don't like looking at the changes 5-6 lines at a time; I 
need to see what the entire structure looks like so I can make some 
intelligent comments on it.

Can't see the forest for the trees.

Ken

Campbell Barton wrote:
> 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).
>>
> 
>