[Bf-committers] Meeting minutes sunday feb 28 2010

[Campbell Barton]

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 <ton at blender.org> 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   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell