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