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

[Toni Alatalo]

Willian Padovani Germano kirjoitti:
> So we are updating the current API with nicer, simpler, safer ways to 
> do things.

fair enough. but OTOH it somehow also seems to me that with the new bpy 
module we are in fact introducing a new API. it is a new module, with a 
different namespace from the old Blender, and with a new, different way 
of creating objects, instead of the old Blender.Typemodule.Type.New() 
way. so I thought it perhaps does actually give us also the chance to 
introduce other things too, like constructors.

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

but the bpy module does not - only the old Blender supermodule does. so 
is there an actual conflict? i guess with people having done 'from 
Blender import Mesh', and in that alternative future with constructors 
then also 'from bpy import Mesh', it is possible. but is it really a 
showstopper? bpy.Mesh != Blender.Mesh ..

> One of the alternatives considered (updated here to use the bpy 
> module) was addXXX(): bpy.addObject(), bpy.addMesh(), etc., but this 
> doesn't look that nice either.

yah, i actually used that technique in a database/server once, addXXX 
just pointing to a general add method that took the type as an argument, 
and that system also keeping type specific collections of things like 
Blender/bpy does, by something like:

createThing(self, *args, **kwags):
    self.add(self.things, Thing, *args, **kwargs)

create(self, all, _class, *args, **kwargs):
    new = _class(*args, **kwargs)
    all.append(new)

and then the using code would usually do the type specific 
server.createThing('name', 'desc', ..) things. i found that ok for a DB 
but not too nice, and I agree that not the nicest for Blender.

my plan is to stop talking and take time this evening or tomorrow latest 
i hope to write a little module in Python, called 'byp' :) , that wraps 
bpy by adding constructor - idea being that with some actual code we can 
better compare if they really bring problems, and if there would be any 
benefit of having them (Campbells 'solution looking for a problem' 
argument). so it will look like this, i'll try to port some of the pby 
examples to it:

import pyb #just to be explicit about the dependancy ;)

scn= pyb.scenes.active
me = pyb.meshes['mymesh']
ob = pyb.Object(data=me) # new object from the mesh
scn.objects.active = ob

urgh, now i am starting to get dizzy. am getting too easily blurred by 
the Blender-type-specific Object objects, and having a collection with 
an attribute like .active. really have the urge to go towards something 
like this in that wrapper instead:

scn = pyb.act_scene
me1 = pyb.meshes['mymesh'] #object level: these are MeshObjects (aka. Mesh)
me2 = pyb.Mesh('a new mesh', data=me1.data) # new object from the mesh
scn.act_object = me2

BTW: the reason why i changed 'data' from the 1st normal argument for 
mesh.new was that, from my own libs mostly, i am used to have the name 
of the object as the 1st argument. this seems to be the case with the 
old Mesh.Mesh.New() as well - is that being consciously changed now with 
bpy, or did that just slip in? 
http://www.blender.org/documentation/243PythonDoc/Mesh-module.html#New 
vs. err also this says it expects a name, 
http://members.optusnet.com.au/cjbarton/BPY_API/Bpy.dataIterator-class.html#new 


so what is this? from 
http://members.optusnet.com.au/cjbarton/BPY_API/Bpy-module.html
ob = scn.objects.new(me) # new object from the mesh

a bug in the example or the doc? is the 'objects' thing different from 
the other collections, but that is undocumented?

~Toni