[Bf-python] Thought about IRC meeting and beyond

[Toni Alatalo]

On Monday 09 January 2006 16:31, Willian Padovani Germano wrote:
> > 1) The use of True/False over 1/0:
> Hi Joseph. Python itself accepts many things as true or false, as
> discussed previously, but of course we won't go there (we won't accept
> "" as false for functions that don't even expect a string, etc).

err, anything that can be evaluated as true/false should accepted where a 
boolean is expected. those arguments should not be typechecked, just use that 
eval func that python provides. why not just do what python does?

> Ton specifically asked us to give access via objects instead of obdata
> right before the meeting yesterday. I'll ask him to develop his request
> a little more to understand it throughly, so we can discuss.

i think i finally understood yesterday what he means. i guess it was that 
operations on e.g. Meshes should be in MeshObjects, not in MeshData. i dont 
know if it is a valid point, nor if i understood it the way he meant.

but i guess it would, in the new api, make sense to have, instead of the 
current:
meshob = Blender.Get('mycube')
meshob.getType() ==> 'Mesh'
type(meshob) ==> <Blender Object> 

something like:
mesh = Blender.Mesh()
type(mesh) #==> <'Blender Mesh'>

and then:
mesh.data would be a MeshData object?

but we definitely need more info from Ton.

i guess i already went away there from what Ton said, but do realize now 
(again :) that there are no instances of Object in Blender. Every Object has 
a type, like Mesh or Armature. so also in the API it should not be possible 
to do Object.New() - only Mesh() Armature() etc., and then the respective 
members should be in those classes, like armature.action and 
mesh.data.vertices (what would a MeshOb have directly?). Blender.Object is 
only like an abstract superclass - in a pythonic api i guess the only reason 
to have such a type would be enabling subclassing it by py classes to 
implement new Blender types, which the current internal architecture of 
course prevents. so the all-new api should not have Blender.Object at all? 
except that there should be some way of getting an object without knowing 
it's name of course .. perhaps that would be in a dictionary in the Blender 
module and in Scene objects, Blender.objects['mycybe'] or something, and 
Blender.sels_objects .act_object etc.

you did ask me not to bring up issues for the all-new api before the cleanup 
of the current is done, so am sorry having violated that request now :/

> A related issue is what Campbell has pointed a few times: Object.Get()
> returns all objects in Blender, not just the ones in the current scene.
> This is bad for exporters, for example. We might simplify things, since
> getting from current scene is a more common request, and make that the
> default: .Get(fromAllScenes = False) or something like that.

or advice exporters to use Scene?:

objects_to_export = Blender.cur_scene.objects?

> Willian

~Toni