constructors (Re: [Bf-python] More Proposed API changes.)

[Campbell Barton]

Id say that as long as scripts from 2.43 still run its fine..

I dont think people should/would do "from bpy import *" - the point of 
having bpy - is the names so short you dony have to import *

most scripts would define the scene.
   scn = bpy.scenes.active

since most of the user context stuff is stored in the scene.

o = Object(bpy.scenes.active)

- its not that bad but I dont want to have 2 ways to add objects when 1 
is fine + less confusing.

   mb.elements.add(..)
   scn.objects.new(..)
   bpy.scenes.new(..)
   me.faces.extend(...)

similar to
   list.append(..)
   set.add()

All work the same way, and they all create data in blender directly.

once the user understands this, its consistent and makes sense.

even if
   o = Object(bpy.scenes.active)

how does that apply anothe type like metaballs?
   elem = MetaElem(mb)


ok, in that case bpy is going to have a massive set of types attached to 
bpy. - OR we have.....  elem = bpy.metaballs.MetaElem(mb)
this starts to get into the relms of inconsistant and a hard to remember 
  API.

Basicly, if its proposed we have bpy.Object() - make a new object. Id 
like to see it fit into the big picture. - apply to meshes, verts, 
metaballs, bones etc.





Ken Hughes wrote:
> Willian Padovani Germano wrote:
>> Hi guys,
>>
>> Again, let's remember what this development is. We are not right now 
>> developing a new API. For months we waited and discussed and so on and 
>> finally saw, a few months ago, that it was not time to redo BPy and 
>> that we actually didn't even have a clue about when the time would 
>> come. This came from discussions in Sunday meetings, etc., based on 
>> plans for Blender itself.
>>
>> So we are updating the current API with nicer, simpler, safer ways to 
>> do things.
> 
> I'm OK with calling this an "API update" as opposed to a "API redesign". 
>  But we should probably decide where to draw the line between the two. 
>  And I can understand Cam's impatience with moving forward, as we've 
> been talking about these things for at least two years, but I still feel 
> better if we decide on *what* to implement before implementing it.
> 
> BTW, who are our benevolent dictator(s)?  Hope I'm not one of them, 
> otherwise I've missed some meetings in Aruba I'm sure.  If we don't 
> really have any, and this discussion isn't making any headway, we should 
> select some.  Again, I'm not in any hurry, but I also don't see a point 
> in dragging out a discussion needlessly.
> 
>> Joseph Gilbert wrote:
>> (...)
>>> Why not:
>>> o = Object(bpy.scenes.active)
>>> instead of
>>> bpy.scenes.active.objects.new() ?
>>
>> The problem here is that BPy uses Object, Mesh, Lamp, etc. etc. as 
>> module names. Making them become constructors would break everything. 
>> And using Object.Object(), Mesh.Mesh(), etc. is not that friendly at 
>> all and it's just adding aliases (Mesh() vs. New()) to our old way of 
>> doing things.
>>
>> We could then put the constructors in the new bpy module: 
>> bpy.object(), bpy.mesh(), etc. 
> 
> I like (or don't dislike) a constructor such as bpy.object() or 
> bpy.Object(), etc.... in fact, I'm OK with bpy.objects.new() as well.
> 
>> But "object", "mesh" and so on are very common var names used in lots 
>> of scripts out there. Upper case wouldn't work either, because of the 
>> problem with module names, again.
> 
> I don't follow this.  I can see how "from bpy import *" could cause 
> confusion if used in conjunction with "from Blender import *" since 
> Object is in both name spaces, but isn't that the case with any module? 
>     Same for "object".
> 
> There are going to be trade-offs no matter what we pick.  The question 
> is will scripting be easier and more stable as a result?
> 
> Ken
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
> 


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