re: python api stability. There are a number of issues here. Firstly, IMHO the commonly used parts of the API are fairly stable, any breakages we have I think will not create significant work for people who have already written scripts for 2.5.
At the moment we have the problem that parts of the RNA api and the python RNA wrapper are not well tested, removing these parts was suggested however I think this doesn't solve anything since we will need them (even in the short term for durian). Some examples... - editing animations from python (inserting keyframes, removing keyframes, editing fcurves isnt complete) - add object operators takes 32 layers (to account for local view), which is not nice for api style access from python. - creating meshes works but I think this part of the api still needs review/standardizing to improve. - Editing text objects from python isnt well tested, assigning fonts etc. More on API design level, these need attention - calling operators fom python with a context other then EXEC_DEFAULT, the way it works now should probably change. - unregistering classes is not stable (leaks memory), possible api changes will be made to fix. - Running operators from python gives memory leaks with report lists, need to investigate. - Some places we have var.add_foo() others var.foo_add(). we need to standardize on ordering of function names. - many operators are not made for api like access, example to insert a keyframe... bpy.ops.anim.keyframe_insert_menu(type=-3, confirm_success=False, always_prompt=False) The API is simply work in progress, calling it stable and locking it down doesn't help because the are parts that are not well tested or only tested in simple cases. This isn't made easier by the fact I'm don't have development time allocated to this while working on Durian, I mainly fix bugs as I find them and make improvements in my spare time / weekends. So we better just call this alpha (incase having blender as alpha isnt obvious enough), can add the word alpha in more places if it'd help :), api docs etc. Longer term we can do managed breakages, for instance, Brechts new shader system will probably change material access, rather then attempting to map back to the old rna properties, we're better off to document what changed and include in release notes. This is the same if modifiers become nodes or any other large update to blenders internals. In 2.4x we attempted to maintain API compatibility with internal changes and IMHO it didn't work well, normally breaking scripts which used the API for anything non-trivial. (examples* UV&vcol layers, new armature internals, replace Sumo with Bullet left dangling api functions which did nothing). On Sun, Feb 28, 2010 at 6:29 PM, Ton Roosendaal <[email protected]> wrote: > Hi all, > > 1) 2.5 test build > > - A new testbuild for 2.5 alpha1 is required, especially the 'textures > get lost' bug makes it unusable. > > - Proposal: get confirmed that this bug has been fixed, and check if > svn status is at least a bit acceptable. Unless showstoppers get > reported here, we call for Ahoy tuesday end of day eurozone. > > 2) Current projects > > - Campbell shows py api examnple for modal operators + drawing callback: > http://www.pasteall.org/11346/python > > - Long debate then lead to confusing state of stability and usablity > of Python API. > Ton's remark was that most people perceive new API calls to "part of > the specification" whilst this is according Campbell "just alpha and > users should accept it will change". > > - Agreed was that Martin and Campbell would summarize this topic to > mailing list, and especially about what is considered good py api > design! What's more or less 'stable' and what not? > > - Quite some time was also spent on python security topic. Still needs > more clarity... or clear proposals for how to move on. > > Note for all: new default for .blend loading is to not run Py scripts > in this file, until better system gets agreed on. So it's "safe" to > load .blend files in current svn Blender. (no warrenty! :) > > 3) Python registry > > - Martin feels like there is useless duplication in registry of > scripts, and proposes another method. Will send proposal to list! > > > -Ton- > > ------------------------------------------------------------------------ > Ton Roosendaal Blender Foundation [email protected] www.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
