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

[Toni Alatalo]

Ken Hughes kirjoitti:
> Something seems inconsistent with this example:

yes, i was not being explicit about the ob / obdata separation .. in my 
thoughts while writing that up:
(afternote: it appears my 'short' comments to other people at the end 
became the more substantial part ot this post though, so Matt, Steven, 
Joe, Campbell etc. see from there if you care :)

> Toni Alatalo wrote:
>>> having bpy.Group() and bpy.groups seems to over complicate things
>> then again, Group is already there .. 
> So you're proposing a constructor here for a BPy Group object....
>>> * ob = bpy.Mesh(scn, me) - is adding the mesh to scn, seems less 
>>> logical.
>> no, it is not about adding a mesh to scene, it is creating a new Mesh 
>> while working on a scene :)
> And here you're proposing a BPy Object constructor with mesh data? 
> Wouldn't the Mesh constructor return a BPy Mesh?  Or is the 
> constructor overloaded and returns different BPy types depending on 
> the context?

my thinking tends to escape to a future where there is no Object, except 
as an abstract basetype, that MeshObject, ArmatureObject etc. implement. 
this being in-line with Ton's argument that the api should be 'object 
level'. so i was thinking of Blender-type specific object wrapper 
constructors, one of them being Mesh (which has the datablock of type 
MeshData as mesh.data). so Mesh(scene, data) would return a wrapped 
Blender-object of type Mesh, bound to that scene, using the given data. 
but that is another discussion and not topical now, sorry about the 
confusion, back to the point:

short comments to other arguments:
- i agree with Steven that Matt's dichotomy of 
nice-for-Blender-scripting vs. normal-Python is false. it is a point to 
consider though. i think things that help users to do simple things 
quickly could be done on the UI level too. like for the Nodes, which 
have complex code structure requiring subclassing Node and overriding 
__call__, the idea was that the UI provides a nice textarea where a user 
can just write the node script and the system takes care of boilerplate. 
or use the nodefactory utility function i posted once. similar ideas 
thrown out here for general scripts are having the 'add new' to 
automatically add the 'import bpy', or perhaps better have the script 
textblock handling code automatically import 'bpy' for texts called 
*.bpy (which would be a new default for 'new script'). i think my main 
concern for having the bpy automagically there for everything is that it 
would hide the dependency - the .bpy extension would make it explicit, 
and similar systems are used in other Python tools (like Quixote .ptl 
web page template files are Python that is handled specially). other 
helpers like a drag&drop from UI would be cool - perhaps already 
possible for e.g. getting a handle to an object? and with the event 
refactor we perhaps could get function calls by dragging from the 
associated buttons, even?

- regarding possible constructors, Joe lost the crucial point here: "So 
if a user does, "mesh = bpy.Mesh()", is he going to realize that mesh is 
automatically added to bpy.meshes?  What will he think, when he realizes 
it isn't garbaged collected?" like shown before, in that proposal the 
constructors for Scene members require passing a scene instance as a 
'parent'. that tells that the new thing will depend on the scene and not 
be independent. that is how at least some existing similar systems 
(scenegraphs) like Soya3d work (i still dont recall how ogre / cs). 
admittedly that may not be the most obvious for a scripter, but i just 
wanted to raise this possibility 'cause constructors are normal and 
typespecificcontainer.new unheard of.

a new thought: as there always is an active scene (right?), could the 
default scene in a constructor be that? it would be most straightforward 
for a scripter i think .. just do newarm = Armature() .. instead of 
armatures.new(). (this issue being independent of whether that'd be an 
object or datablock..). allowing this would invalidate the 
counterargument to Joe's critique above, though. but it is just a part 
of how Blender works: if you create Blender objects or data in the UI, 
they of course automatically become a part of the project. and getting 
rid of them is hard (the save-reload cycle :). so i think it would be ok 
that the normal Python syntax, which is also shorter to write :), would 
mean the normal Blender behaviour, that you must know when you work with 
Blender. Campbell's argument againts constructors, that then a scripter 
must know about two things: armatures and Armature, is i think weak: to 
be able to use an armature he has to look at the Armature class 
documentation anyway, and understand the difference of the collection of 
all armatures vs. a single armature. so i think it would be good to have 
the creation in that standard place that we already have, the class, 
which is a familiar mechanism for i guess all users who have ever used 
Python for anything else.

but like said it also is a point that the new unique-to-Blender system, 
using typespecificcollenction.new() instead of Type(), would point out 
the difference of Blender vs. Py lib behaviour. i am not sure it is 
necessary though - we could just provide the standard interface, and 
point out just by saying in the docs that also thru normal Python, 
Blender objects/data behave like normally in Blender.

i agree with Campbell that points have been made and the issue is up on 
the air. am fine with the call for the dictators decisions, and will 
probably be happy however that turns out, 'cause the new bpy module is a 
great improvement anyway (and no Ken, by that i don't mean the 
autoimport, but the fact that the largely redundant Blender.Datatype 
modules are out of sight - data via bpy is very directly accessible and 
usable, just like it should!)

> ken

~Toni