[Bf-committers] ops functions, parameters, and returns

[Campbell Barton]

Hi Charles, answers inline.

On Sat, Mar 20, 2010 at 3:36 PM, Charles Wardlaw
<cwardlaw at marchentertainment.com> wrote:
> Hi all,
>
> Finally got some time to sit down and do some API programming.  I know everything is in flux, which is why I wanted to bring up this topic now.
>
> I have a few questions about thought process behind the API:
>
> - Editmode toggle: why is it just a toggle?  Why can't it be set to a value like it was in the 2.49 API?  Seems to me the old way (x = editmode() / editmode(x) ) worked pretty well
Toggle is just was the key runs, you can also do
 bpy.ops.object.mode_set(mode='EDIT')
to chech you can do
 is_editmode == (context.mode == 'EDIT')

> - Why don't the bpy.ops functions that create things return what's created?  It seems very roundabout to have to create something and then slurp it out of bpy.context or out of object data.  For example, I'm playing with adding bones to armatures.  After making sure I'm in edit mode and adding the bone, I then have to drill down somewhere else to get the bone to move its head and tail.

> Similarly, why don't they return a tuple of items that's indexable instead of a set, which isn't?

Operators are tools and not api functions, the idea is that operators
manipulate the context so python can be used to create macro's
What an operator would return isnt always clear, for instance if you
link in objects, would it contain a list of every object, scene and
text blocked linked??

however in some cases its really obvious that you would want to run an
operator and get a return value, in these cases we should probably
make RNA function calls for these operators (internally they can use
the same C functions).
There are also quite a few cases where the operators should be removed
and only have API calls only. Things like "Move Modifier Up" IMHO are
not useful as operators.
But then we need to see how rna function calls can be done from the UI :S.

We could try to make operators behave more like API functions but this
is not a small task and not what operators were originally designed to
do. so I think its out of the scope of 2.5 tool refactor.

> - bpy.ops.object.armature_add() - specifying the location moves the pivot of the entire armature object, but the single bone that gets added is still placed at the cursor.  Is this a bug or a feature?
> - bpy.ops.object.armature_add() can't specify a name on creation -- is this intentional?  Actually it seems that many of the adding functions can't.

There are many many inconsistencies in how operators work at the
moment, this is one reason I dont want to call blenders API stable too
soon!
Different developers wrote operators, mostly to get blender working
again and not having read how all other operators work. When you try
use operators from python you end up finding many problems like this.

for data creation and removal though we accept that operators are not
ideal and there are existing functions for this
 # Example
 arm = bpy.data.armatures.new("MyArmature")
 obj = bpy.data.objects.new("MyObject", arm)
 scene = bpy.context.scene
 scene.objects.link(obj)

> I'm sure I'll have more as I go, but if anyone could help me understand why these parts were done this way I'd greatly appreciate it.
> ~ C
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell