<ideasman_42> so I guess you know my rationaly for having things the way they are at the moment..
rationale*
<ianwill> like the examples I put here: http://mediawiki.blender.org/index.php/Talk:BlenderDev/BPythonAPI/ObjectCreationAPI
<stivs> you can remind us
<ianwill> grep for "scene.add(MESH)"
<stivs> the overloaded add() method?
<ianwill> but we'd better focus a little on what we'll do for this version: update Object.New and keep scene.objects?
<ideasman_42> ianwill, IMHO context sensitive add is nice only if people use good variable names.
<ianwill> stivs: the mammoth add function with all its cases :)
<stivs> should all our containers by pythonic and support an append() method?
as well as the mega-method scn.add() ?
<ideasman_42> stivs, .add() where doubles arnt allowed and .append/extend where they are.
<ianwill> let's discuss the word "add". Is it good in scene.objects.add? What is it?
we could do with new and link
new: add new something
link: link existing something to this "container"
that's what BPY has been using
<khpylon> Blender UI uses "Add" for objects... .add() would be consistent
<ianwill> otoh add could mean both new and link or just link
<ideasman_42> link is blender lingo, add() is python
<ianwill> notice also that these additions to the API are for our *alternative* API, that should be simple and nicer, so we're somewhat free not to follow old bpy naming conventions
<ideasman_42> having add/link as the same function is no good, Iv thaught abt it and its not good because its unclear if it returns a new object ot not
<ianwill> in other words, we can fix naming where needed
<ideasman_42> (oops I mean new OR add/link)
<stivs> add and link should be separate methods.
<ideasman_42> at the moment scn.objects.new() and objects.add() could be the same function but its not good design
<ianwill> and then "add" means "new", is that it?
<ideasman_42> scn.objects.add(some_existing_object)
<ianwill> ah sorry, there's an important point I'm forgetting: what we pass to add or new
yes, ideasman_42
<ideasman_42> new_ob = scn.objects.new(some_Ob_data)
<ianwill> if we pass an existing ob wrapper, then it's just linking, if we pass ob data wrapper or a constant (if supported), then a new ob is created
<khpylon> I like the idea of overloading .add() to do new or link
one less thing for users to remember
<ideasman_42> khpylon, disagree.. do you see why?
one always adds an object. the other always uses the existing.
<khpylon> you mean if you add the object to the scene twice
?
<ideasman_42> nope..
say you are reading sombody elses code...
and they have a var called mesh
scn.objects.add(mesh)
how do you know if mesh is obdata or an object?
therefor how do you know what add() is doing.
<ianwill> scn.object.add(data = mesh)
scn.objects.add(data = mesh)
forgot the 's'
we can force the user to specify that a data ob is being passed
<khpylon> if they have a variable called mesh, you can read the code to see how it was created
<ideasman_42> scn.objects dosnt have many functions, I think keywords should only be used to set options, not define what a function does.
<ianwill> add(ob = None, data = None, name = something)
<ideasman_42> thats for the function name.
<ianwill> it depends on how many ways we allow for adding objects to the scene
<ideasman_42> scn.objects.new() - is nice an explicit. you are making a new object.
<ianwill> and it accepts what as param(s)? Object type, name, etc. like Object.New() ?
<ideasman_42> it uses the dataname by default as the object name
<ianwill> we gotta write down all cases (ways to create and link ob to scene) that we want to support, then see if it can be done with one, two or three methods (new, add, link)
<ideasman_42> it cold also accept a name if the scruipter wants but thats not uimplimented
<khpylon> what does link() do again?
<ideasman_42> same as add?
* stivs suddenly wonders that too
<khpylon> ok, so it wasn't just me
<ideasman_42> link only deals with existing objects
<khpylon> and add?
<stivs> so we have add() /new() vs new()/link() ?
<ideasman_42> to make scn.objects look more like a set() Iv called it .add()
but it could be .link()
<khpylon> so we are only talking about two options
<ideasman_42> I think so?
<ianwill> yep
<ideasman_42> tho add could also mean adding a new object like in the menu but maybe best not go there for now
<khpylon> no, I think we should go there
one complaint for new scripters is we're too pythonic
<ianwill> link would only accept ob wrapper as param and try to link it to the scene
<stivs> ooh, the menu. and the principle that bpy should look like the ui
<khpylon> yep, somewhat
<ianwill> khpylon: let's complain back that they are not pythoninc enough :)
pythonic
<khpylon> I see a lead baloon....
<stivs> we should be both pythonic and blenderific
<khpylon> balloon even
<ideasman_42> (ui following should be done with a grain of salt. some areas have not been thaught out that wel)
<ianwill> yep, we should follow good py practices and try to be nice to blender
I prefer to read complaints from bpy newbies than from good py coders (the later are more informed and have good points, I'd feel ashamed)
<stivs> true.
<ianwill> and, seriously, with python in many projects, all we can hope is that they all follow pythonic ways and we can all get along
* stivs remembers that point for when we talk about 'import Blender'
<ianwill> argh
<stivs> heehee
<ianwill> then I'll have to see how they do in gimp, inkscape, etc. etc. :)
<stivs> inkscape has py scripting?
<ideasman_42> yes
<stivs> cool.
<ideasman_42> so does k3d ;)
<ianwill> ok, do we agree about updating Object.New() to automatically link to a scene (and make scene.link no complain if ob is already linked) ?
s/no/not
* stivs thinks yes
<khpylon> yes, but also automatically creating obdata.....?
<ideasman_42> IMHO its a fairly big change and may break some scripts. better let Object.New() smolder and depricate it the way it si
is*
<ianwill> that's the second point. It used to be like that, I ( *blush* ) changed it to avoid creating / deleting data, since users used NMesh.New(), usually.
<stivs> ideasman_42, hmmm, interesting point.
<khpylon> how about we allow obdata as an option, and print a warning to the console if they don't pass it?
<ianwill> ideasman_42: the change doesn't seem that harmful
<ideasman_42> probably wont effect simple scripts but for some I know it will.
<ianwill> ideasman_42: example?
<stivs> console warnings are not too visible
* khpylon runs linux
<ideasman_42> not really. but some of my scripts deal with objects in multiple scenes
<ianwill> ideasman_42: and they link the objects to the scenes they need to, right?
<ideasman_42> for example- a sctipt that imports objects into their own scene-
<ianwill> that won't change
<ideasman_42> if they are created before the scene is set it will
<stivs> khpylon, me too. all praise to the console.
<ideasman_42> linux here too ;)
<ianwill> yes, this script will end up adding objects to that scene and the current one, too, that's a problem. But I guess it's better to update that script than to deprecate Object.New right now.
<khpylon> what about tracking when objects are created new, and if they are assigned to a new scene we remove from the default before linking to new scene?
<ideasman_42> Im not that fussed tho. just think its a farily big change and if people have to change how they use Object.New() NOW, then they may as well not bother and use scn.object.new()
<ianwill> one point about deprecating is: will we deprecate also NMesh.New, Mesh.New, Camera.New, etc. etc. ?
<ideasman_42> replace with what/
<ianwill> khpylon: an option, but that would bring confusion for newer scripts
<khpylon> ianwill: encourage newer script to not use Object.New() !
<stivs> khpylon, that sounds a little complicated conceptually.
the linking thing, I meant.
<ianwill> if we make it safe, it's not a bad option anymore
<khpylon> stivs: just a flag set inside the BPy_Object struct
it's a kludge, but one way to handle in the meantime
<stivs> khpylon, I meant from the scripter's perspective
<ianwill> Object.New has a bad reputation among devs like kaito and us because users can misuse it. If we force it to link to a scene and maybe also add ob data, it becomes a well behaved function, no?
<ideasman_42> khpylon, not too font if python doing tricks buhind my back, reminds me of microsoft.. but Ill be happy to let it be evil and just not use it.
<stivs> it *does* need fixing. and atm, is a known part of the api
<ianwill> khpylon: the problem is that it's cumbersome for new scripts: I use Object.New() to link to the current scene, but if I also link to another scene later, I'll have to relink to the current, again.
- again
<khpylon> no, the point is maintaining the "current" way linking works
this is for backward compatibility
<ianwill> yes, but it introduces confusion for newer uses
new scripts, I mean
<khpylon> who are using scn.object.add() instead
??
<ideasman_42> scn.objects.new() I think
<ianwill> doc: "this function links to the current scene, but unlinks if you later link to another one"
<khpylon> lol whatever
"for backward compatibilty"
<ianwill> the point, then, is if we want to force (or really recommend) that new scripts use scene.objects, etc.
is that so? Or will Object.New() stay at least until a real API overhaul that is free to remove / change stuff?
<khpylon> i think we do; otherwise they are going to have to rewrite their scripts later when Object.New() is removed
<ianwill> so you're for really removing Object.New, for sure? Do all agree?
<ideasman_42> I thinks so..
<khpylon> yes
<ideasman_42> yes
<ianwill> and what about the other .New() functions? Mesh.New, etc.? Will they stay or go?
<khpylon> not right now, of course
<stivs> by 'remove', you mean 'not fix now'?
<khpylon> I think we still need to try fixing
<ianwill> no, fix now but considering that it's deprecated (so use khpylon's suggestion for backwards compatibility)
<ideasman_42> are there many scripts out there that deal with a lot of objects?
I dont mind if mine are broken but others might complian..
<ianwill> I prefer to fix Object.New and ask / expect that all affected scripts are updated
but I'm democratic, of course :)
<stivs> ianwill, I think that is the right thing to do.
<ianwill> only scripts that create objects and link them to another scene without making it the active one during the script will be affected, of course
<ideasman_42> Im against fixing Object.New() - suspect it will open a can of worms even if the fix seems logical
<khpylon> yeah, but the worms are already on the loose :-)
<ideasman_42> at least they are known
<stivs> heh. if we don't fix it, we should remove it from the docs right away.
<ianwill> the point, ideasman_42, is that fixing it solves (unless I'm missing something) kaito's main long time complaints about bpy
<stivs> to encourage use of scn.objects.new() or whatever it is called.
<ianwill> stivs: for sure, removing from new versions of docs is a weapon we should use :)
<khpylon> also making sure "print dir(ob)" doesn't list it :-)
<ideasman_42> alright. so thats decieded on Object.New()
<ianwill> what is decided?
* khpylon nods
<ideasman_42> fixing it the way khpylon suggested
?
<ianwill> that's not my favorite solution, but if accepted, at least also print a msg to the console warning the user to update the script, I'd say
<stivs> the create obj with auto-scene-link, link to new scene, whoops it is gone from original scene?
<khpylon> unlink from current scene unless a scene is passed as a parameter?
not my favorite either...
but a compromise
<ideasman_42> ok. so khpylon, are you ok to go ahead with that?
<ianwill> see, that's confusing, if we use it we really move to deprecate Object.New() and so Object.Get(), too
wait, ideasman_42, we're still talking
don't go too fast :)
<stivs> adding to current scene is a opengl-like state machine approach.
<ianwill> you guys didn't answer: are we to get rid of all .New functions, eventually? Or just Object.New()?
<ideasman_42> ianwill, I think thats blending into the new API
<stivs> do you need to be able to create an obdata if you want to re-use it with multiple objs
<ianwill> ideasman_42: right now we're not moving to a new API, we're adding it as *alternative*
<ideasman_42> ianwill, ok. so keep .New() and .Get() then..
<ianwill> blending (breaking stuff here and there) is terrible, better break at once than a little each version
<khpylon> I don't think we can get rid of .Get(); how would you get obdata not attached to any object, for example?
<ideasman_42> Blender.objects ? - not now.
<khpylon> Blender.obdata?
<ianwill> stivs: of course we need to be able to create obdata, so either OBDATA.New() stays or something better comes up, along scene.objects. It could be blend.meshes (or blend.meshdata or blend.data.meshes), blend.cameras, etc
<ideasman_42> ianwill, agree-
<ianwill> I thought about blend (can be another name) to refer to the current blend file in memory
<ideasman_42> oh so blend.scenes.active
<ianwill> because objects we add to scenes, but scenes, texts, images - we add to the blend
blend.scenes
blend.texts
scene.objects
<ideasman_42> Nice
<ianwill> scene.worlds
<ideasman_42> world ;)
<ianwill> just an early idea, not for this version
<ideasman_42> ianwill, I like it.. but not now.
<ianwill> gotta see how it "blends" with working with external blends, too, if at all, so it's really for later
<ideasman_42> yep,. libdata is another issue
<ianwill> ideasman_42: do you have an idea about how many (%) of the scripts might be affected by changing Object.New simply, no fix for backwards compatibility?
a rough idea is ok
<ideasman_42> not many- maby 2-6 of mine?
<ianwill> because we're allowed to do such a fix, it's important and kaito will probably like it
that's why I'd prefer a clean fix, even if it breaks some scripts that can easily be updated
<ideasman_42> ok. it should be ok. even if some stuff needs to be changed
<ianwill> we can also inform it clearly in the release page, via forums, etc. It's big enough for that.
stivs and khpylon ?
* khpylon thinking
<stivs> ianwill, could you summarise? (I'm loosing track)
<ianwill> we update Object.New to accept scene (and data?) parameters, it links to current scene if none is provided
<khpylon> maybe adding to default (or any) scene isn't as important; making sure there's obdata is more important.
You can have objects not in any scene now, even from the Blender UI (although I think that's a bug)
<ianwill> but we just document and inform it well, no fix for old scripts
<stivs> ianwill, thx. ok by me.
<ideasman_42> what about just raise an error of the ob has no obdata?
<ianwill> if the issue is just obdata, then it's way easier to solve, are you sure, khpylon ? I thought the complaints were about objects not in scenes.
<ideasman_42> object with no obdata is worse- but I think both were complined about.
<ianwill> we're not communicating well :) , long time no talk, I've been away, etc.
<stivs> objects not in scene *was* a kaito complaint.
<ianwill> that's what I thought, stivs
<ideasman_42> Blender allows objects with zero users. but not objects with no data-
Blenders UI I mean
<stivs> if you are doing it all by hand, it makes sense to create an object without obdata and and it later. but we are talking about a high-level convenience function here.
arg. *and add it later.*
<khpylon> stivs: but the problem is a simple script error (syntax) can create an object without obdata, even when the scripter intended it to be there
I *think* I fixed that
but I might not have anticipated everything
<stivs> so we *should* add an obdata by default in Object.New()?
<ianwill> you can only create an object without data in bpy if you don't link it to a scene (scene.link creates data if not available) or if you unlink obdata from ob later
that's what I remember
adding obdata by default is easy, just revert to what it was long ago, use add_object() to create the object.
<ideasman_42> yes- but the objects still in blender pool of objects. so accessing it could do funky stuff
<khpylon> ianwill: right, that was the bug (created object not not linked to scene)
anyway, you're right; kaito didn't like objects created outside of scene context
that's why he'll be happy I think with scn.objects.add() or whatever
maybe then will overlook anything we do to make Object.New() bahave
<ianwill> khpylon: but the problem we need to fix them is not letting ob's w/o obdata, is that it? If so, it's a small update.
<khpylon> but we're still breaking backward compatibilty to some extent (which I'm OK with); older scripts will end up creating lots of "orphaned" obdata since they link to their own later?
<ideasman_42> yep, thats the problem :/
<khpylon> unless we kludge a check for that too?
<ianwill> that's why I once made this mess not to create obdata, but reverting is better than crashes
<stivs> maybe a nice singleton default obdata, like python does with the first 100 ints?
<ianwill> khpylon: like checking in object.link() if the to-be-unlinked obdata has 0 users, then erase it? That's the way, I guess.
NMesh/Mesh.New is the problem here, users should rather use Object.New('Mesh'), then access mesh via ob.data, we documented that long ago.
<khpylon> er... I was thinking about checking when the BPy_Object is deallocated for obdata==NULL, then complaining somehow
<stivs> khpylon, why is that a problem?
<khpylon> stivs: it's no problem, just need a group hug that it's OK for me to do something like that :-)
<ianwill> stivs: interesting idea, but it wouldn't work unless another check was added to prevent the user from editing that default mesh (adding another "real" one for the user, instead)
<stivs> ianwill, if you edit it via blender, we would create a new 'real' one.
<khpylon> ianwill: ob.data is only needed if the user is accessing something related to object which uses the mesh (e.g., vertex groups)
if that's so, they have to link the data to the object
<ianwill> stivs: no, edit via accessing ob.data, in python
<khpylon> which is a different hairy mess
<stivs> ianwill, that sounds ok. basically the same scenario.
<ianwill> user creates mesh object (we use a default data), then accesses ob.data
when user accesses ob.data for the first time, then you'd have to put a real mesh data ob instead of this default one
<stivs> right. idea is similar to checking for existence of a singleton and creating on the first access if not found.
<ianwill> khpylon: still thinking about your idea, guess deallocation might occur earlier and cause trouble -- aka the user doesn't hold a ref to the new object, but later Object.Get's it back. So giving an error might not be good, but creating obdata automatically in the deallocator might be better (ugh). Thinking...
* khpylon thinks we should printf ("Bad scripter; BAD") to console, then force segfault
<stivs> heh. /me suspects khpylon also beats his students for wrong answers
<khpylon> I prefer the term "flogg"
* ianwill is starting to agree that Object.New is evil
<ianwill> all hail scene.objects.whatever :)
so for Object.New khpylon will try a solution, first, ok? (that's what I understood)
<stivs> and what solution was that?
<ianwill> the deallocator one, guess that's what he'll test, first
but better let him say :)
and that means no automatic linkage of ob to scene
* khpylon wife gets up, sez to say "hi" to channel
<khpylon> yeah, I'll try a solution
just for objdata though, right?
* stivs waves and asks "wasn't auto-link to scene the original goal?"
* ianwill waves hello, wondering in passing what time it is where khpylon is
<khpylon> 8:45am
<ianwill> khpylon: yes
stivs: I thought it was, but khpylon and ideasman_42 said the problem wasn't there, but actually with data linking, only
<ideasman_42> can we aggree on scn.objects if Object.New() is settled?
<ianwill> yes, let's see that now:
<khpylon> stivs: auto-linking to scene was a goal, but doesn't cause crashes if we don't (it just makes baby kaito cry)
<ianwill> scn.objects.new(arg) -- what can arg be?
<ideasman_42> obdata
mesh, lamp etc
and it returns the resulting object
ob = scn.objects.new(myObdata)
if a names needed maybe ...
ob = scn.objects.new(myObdata, 'obname')
name='obname' - whatever
<ianwill> I dislike this mess: scn.objects.new(Mesh.New()) -- new, New, upper/lowercase mess
<ideasman_42> agree
but this new implimentation does solve a big can of worms... and its not the first time BPY is inconsistant
<ianwill> not your scn.object's fault, it's just bad mixing between old vs. new API ways
<stivs> so we are back to scn.add() ?
<ianwill> wow, we're irritating ;)
<ideasman_42> yep. is add() ok. or rename to .link()?
<ianwill> for linking I prefer link
<stivs> or scn.objects.add(MESH) ?
<ideasman_42> I like add- fits with set() like operation and python implicitly links data anyway
<ianwill> that's actual blender linking, though
<ideasman_42> put it to the vote/ ;)
<khpylon> .add() takes existing object and adds to scene, or created new?
<ideasman_42> takes existing
<khpylon> so there would be .add() and .new()
<ianwill> scn.objects.new(type, name = 'object', data = None), guess I prefer that, ideasman_42
<ideasman_42> right...
<khpylon> and for data=None, we create obdata
<ianwill> link is clearer than add (add can mean create and link, link clearly means linking)
<ideasman_42> agree- but less pythonic.. Im not that fussed tho
add does infer new data creation which isnt happening
<ianwill> in Blender add means creation of objects, as someone (sorry) pointed
<ideasman_42> oki. link it is
<khpylon> ok
<ideasman_42> about new now..
ianwill, Im ok with your suggestion for the mostpart
however ob = scn.objects.new(obdata) # should work still
<ianwill> why?
<ideasman_42> because your giving the function all the data it needs
and its much less wordy
<ianwill> that's not very readable
scn.objects.new(yadda)
from reading that you don't know what that is until you check the script or the docs
<ideasman_42> IMHIO its fine. yadda has to be obdata and your ok
<ianwill> only after you know that, yadda could be a name or a type, too
<khpylon> btw, kaito once told me that object type is determined by obdata, not by the ob->type field
ob->type is just a convenience
<ideasman_42> it could be scn.objects.new_fromdata(somedata)
<ianwill> you really dislike scn.objects.new(data = yadda), don't you ;) ?
<ideasman_42> yes
<stivs> keywords *are* pythonic!
<ideasman_42> I have had to use me= ob.getData(mesh=1) SO MEANY TIMES.. and its annoying
<ianwill> that's another issue...
<ideasman_42> right, but I think in the common case- keyworkds arnt that benificial
its ok to have the user read the docs to see what kind of data objects.new() takes
<ianwill> btw, khpylon and all, is Mesh ok already for us to force sccn.objects.new() to use mesh and not nmesh, or is it a bad idea?
<ideasman_42> if there unsure
ianwill, scn.objects.new acceprs both NMesh and Mesh
its only taking it as an arg so it does both
<ianwill> I know, but it could be a good time to not support NMesh, if Mesh is to get rid of it eventually
so, ideasman_42 , do you still need NMesh? Will Mesh be able to completely replace it?
<ideasman_42> hrm... dont think getting rit of it by not supporting it in new parts of the API is the way to go
<stivs> which do we create if it is not provided?
<ideasman_42> Im happy for NMesh to go anytime tho ;)
<khpylon> is there still anything in NMesh missing from Mesh?
<ideasman_42> dont think so
<ianwill> I don't know
<khpylon> keyshapes was the last thing I recall, and I think ideasman_42 added those
<ideasman_42> khpylon, yes. using old nmesh syntax- hope thats ok
if not can change- it was a copy paste
(from NMesh)
<khpylon> no problem; that's how 90% of the Mesh API was developed
<ianwill> well, about the scn.object.new() using data keyword or not -- ok, data can be the first param imo (so scn.objects.new(data) works), as long as we only support that way to create an object: create or grab obdata first.
<ideasman_42> Almost certain no NMesh stuff exists that Mesh dosnt do
ianwill, having verbose is ok too. new(data=foo, name=bar.....)
<ianwill> then, ideasman_42 and khpylon : I suggest you consider not supporting NMesh in scn.objects.new and other new API stuff
<ideasman_42> Im not sure about 'type' though
<ianwill> ideasman_42: forget type then, if we go for a single way (always have to provide obdata), that's not a bad way
<ideasman_42> ianwill, or maybe obdata could be used as well as the type..
<stivs> use type for primitives?
<ideasman_42> so ob = scn.objects.new(Blender.Types.Mesh)
<ianwill> later we can have that scene.add function that can create objects in other ways, like from constants refering to primitives (CUBE, PLANE, etc), etc.
<ideasman_42> stivs, nope I mean type() typoes
<ianwill> better have a single way in scn.objects.new, or we end up with the same troubles of Object.New, no?
<ideasman_42> yeah!
just saying if we wanted new() to make the obdata so as to avoid.. Mesh.New() - thats 1 way
so, my todo is to rename add() to link()
<ianwill> if the user can only create by giving data already, they won't create mesh ob, then data, then link, like now.
ideasman_42: yes, good
<ideasman_42> and make adding/rem objects while its loopiong raise an error
<ianwill> yes :)
-->| kramer3d (n=kramer3d@ip72-196-202-74.dc.dc.cox.net) has joined #blenderpython
-->| theeth (i=theeth@www.blenderartists.org) has joined #blenderpython
<ideasman_42> hey Theeth! -JUST got back
<ianwill> hi theeth
<ideasman_42> 95f here
<theeth> hey willian
-->| joeedh (n=chatzill@student53111.student.nau.edu) has joined #blenderpython
<theeth> ideasman_42: argh!
<ianwill> and hi kramer3d and joeedh , too :)
<joeedh> hi ianwill e
<theeth> ideasman_42: did you get to see the snow storm before leaving montreal?
<ideasman_42> just once..
<kramer3d> hello
i will just be reading stuff contributign nothing :)
<ideasman_42> lurker!
<khpylon> odd; I will be contributing stuff and reading nothing!
<ideasman_42> so.. theeth you didnt like this.. ob = scn.objects.new(None) # makes an empty
thats how it works now.
<theeth> no, it's too magic
<ianwill> argh, had forgotten about that
<theeth> that is, it could happen by accident, on error
<stivs> theeth, good point.
* ianwill has the strange feeling that when things don't fall into place, something is broken...
<theeth> that's asking for people to check input before pcalling bpy
<ideasman_42> theeth, if thats the case- they will know why empties are created.
<stivs> maybe this is where creating Blender default objects comes in.
<ideasman_42> stivs, ogl like state?
<stivs> scn.object.new(EMPTY), ...new(PLANE)
<theeth> and the only way to create an empty is through the default object
<stivs> no, not a state machine, but stuff on Add menu
<theeth> since empties don't have data
<ianwill> back to scn.objects.new(type, data = None, name = 'object')
<joeedh> maybe name should be before data?
<stivs> ianwill, a great idea!
<joeedh> type, name, data?
<stivs> name is optional.
<theeth> name shouldn't be optionnal
<ideasman_42> ianwill, cant that condence down to cn.objects.new(data = None)
<joeedh> well yeah, but so is data in that example.
<ideasman_42> theeth, why/?
<stivs> that means either keywords or optional orgs at end.
<theeth> ideasman_42: for what stivs said
<joeedh> hrm. I think theeth is right. if name is optional, then you get auto-generated names.
<stivs> like you do in blender?
<theeth> at least make it the first optional arg
<ideasman_42> joeedh, at the moment names are made from datanames
<theeth> then you could do: scn.objects.new(MESH_PLANE) and have a default mesh plane with a default name
and scn.objects.new(MESH_PLANE, "my plane")
<joeedh> should we insert constants like MESH_PLANE into __builtins__ (or maybe the script namespace dict) or just have them in Scene?
<ideasman_42> cant we leave that up to Mesh?
<stivs> we *do* have the ability to overload methods based on number of args
<ideasman_42> Mesh alredy has promitives
<ianwill> joeedh: they should be accessible from the root namespace, yes
-->| antont (i=[U2FsdGV@pallas.utanet.fi) has joined #blenderpython
<antont> hops
<joeedh> antont!
<khpylon> ianwill: ugh; namespace pollution
* joeedh pastebins logs of what he's seen so far for antont.
<stivs> antont, hops as in jumps or hops as in beer?
<ianwill> ideasman_42: the point is finding a good API that supports nicely empties, meshes, etc.
<theeth> not in main namespace please
<khpylon> theeth: agreed
<joeedh> antont: http://www.rafb.net/paste/results/6hzptp63.html
<theeth> if people want to use them without prefixing, they can just use import from
from import, rather
<ianwill> at least we need a way to avoid too much useless typing, verbosity
<antont> stivs: more like jumping
<theeth> ideasman_42: having people create the mesh primitive first and then link it through a new object in a scene is far from the UI
<antont> joeedh: thanks!
* antont reads
<ideasman_42> if its None opposed to Blender.Foo.Empty Im still prefering using None
<joeedh> antont: you're welcome.
<ideasman_42> theeth, yes..
<khpylon> ianwill: so first param must be either obdata of some sort of constant for type?
<antont> ideasman_42: i am againts using None for Empty, and for using either a constant or a type (EMPTY or Empty)
<theeth> I too
<ideasman_42> is it wise to follow the UI riht how since it will be refactored? :)
<joeedh> ideasman_42: hrm. the Draw constants are nice, because Draw is only five letters + the ".". maybe we could put the constants in Object? that's a little longer, but not as long as Geometry.
<antont> ideasman_42: empties are not none - they are not like NULL in c - they are objects that have information. they are not nothing
<theeth> ideasman_42: I highly doubt adding new primitive will change that much
<ideasman_42> antont, in the context it works
your adding an object from its data- and empties have no data
<theeth> joeedh: from Blender.Object.Primitive import * TADA!
<ideasman_42> adding an object from data*
<ianwill> khpylon: undecided
<joeedh> eek no Primitive!
<theeth> joeedh: that was an example
ideasman_42: it's twisting the meaning of none
* joeedh would die if there was a Primitive dict, can't we put constants inside the module?
<antont> ideasman_42: ah, good point, i did not know scn.objects.new takes an object - i thought it takes a type, am reconsidering now
joeedh: yes we can
<joeedh> I'd rather do Object.MESH_PLANE then be forced to do from Object.Primitive import *
<stivs> antont, we are still discussing the args and their position
<ideasman_42> new_ob = scn.objects.new(some_ob_data)
<khpylon> and/or new_ob = scn.objects.new(SOME_PRIMITIVE)
<ianwill> the only way to solve this is to write down all the different cases and suggest a signature that solves them all nicely, also fixing current troubles
<antont> ideasman_42: for me that looks like a rare special case, hmhm, but i case that is a common use case in your scripts
<theeth> if the parameter is not an object data type, throw an error
<ideasman_42> Id like to deciede on how empties should fit in first
<stivs> ianwill, yeah. doint little examples (aka "use cases") is a good idea.
<theeth> for empties, use scn.objects.new(EMTPY)
<ianwill> that sounds interesting: some_ob_data or SOME_PRIMITIVE, including EMPTY
-->| UnNamed (i=500@16.Red-80-32-164.staticIP.rima-tde.net) has joined #blenderpython
<theeth> from a UI side of thing, you never create an empty from some none data, you always create the primitive
<joeedh> UnNamed: http://www.rafb.net/paste/results/QAsW8i40.html for logs of what you've missed, if you're interested.
<ideasman_42> dont think the UI stuff translates usefully in this case
[INFO] The view #blenderpython has been successfully saved to /home/khughes/#blenderpython.html.
<stivs> None has such a special meaning in python. so bad to overload it, IMHO.
<antont> if it would be scn.newObjectFromObdata(obdata), and it would be only for that, i would understand using None but perhaps still would not think it is good. but for a .new() that takes both data and types, None is not an option for me.
<ianwill> 1) scn.objects.add(obdata) # works for all ob types except empty
<UnNamed> joeedh: tx
<ianwill> 2) scn.objects.add(PRIMITIVE) # constants refering to mesh or other type primitives (CUBE, PLANE, etc) and EMPTY
ack, read new where I used "add"
1) scn.objects.new(obdata) # works for all ob types except empty
2) scn.objects.new(PRIMITIVE) # constants refering to mesh or other type primitives (CUBE, PLANE, etc) and EMPTY
<ideasman_42> ianwill, Im happy with that
<ianwill> is that it?
<theeth> and for both methods, have the name as second optional argument
<ideasman_42> theeth, agree wow.. ;)
<antont> what about just scn.addMesh(), add .. ah /me finally realizes primitive != type here
<theeth> and scn.objects.new(none) throws an error
<ideasman_42> yes!
<ianwill> yep
all agree?