[Bf-python] Proposed BPyAPI Additions.

[Willian Padovani Germano]

Hi,

There's a point up for discussion below, marked [***].

Ken Hughes wrote:
> Good discussion on IRC yesterday;  unfortunately my system crashed 
> before I had a chance to save out the IRC session.  Can anyone 
> summarize?  How much needs to be done to clean up prior to 2.43?

For 2.43 the required changes were, as far as I recall:

1- Fixing Object.New();

2- Making discussed changes to scene.objects:
- naming conventions (new, link);
- forbidding len(scene.objects) to change inside loops;
- making scene.objects.new() accept either an obdata wrapper or a 
constant to (for now) indicate Empty objects: scene.objects.new(EMPTY).

Campbell already committed some changes for scene.objects (and 
group.objects, too).

For the constant we need: for now it's enough to have the EMPTY one, 
later also for primitives (cube, plane, etc. etc.) (*). We still didn't 
decide where to put these constants.

(*) Probably better *not* to support constants for basic ob types 
besides EMPTY, to force users to always pass obdata to scn.objects.new() 
if they want a mesh, camera, lamp, etc. -- to prevent the same problem 
we're trying to fix in Object.New() right now.

[***] Remember that you disliked how (because of int constants) one 
could either write things as e.g. scn.objects.new(EMPTY) or 
scn.objects.new(0) (or whatever number EMPTY referred to), Ken? A clean 
way to solve this is to use constant strings, so EMPTY would refer to 
"Empty" and not a number, for example.

If we go that route (that'd be a change in our current plans that should 
become part of our guidelines and propagate to future API updates where 
relevant, of course), then Campbell could easily update 
scn.objects.new() to accept the string "Empty" as argument and later we 
could decide about where to put the needed constants. Extra benefit is 
that users could either write the constant EMPTY or the string "Empty", 
both would work and be equally readable.

> Regarding fixing Object.New() to protect against objects with no obdata, 
> I can only see two solutions.

If we're confident the ob deallocator is always called, even if the 
script fails (I can't test right now), then your solution to change type 
to Empty could be done there, upon checking that type != Empty and 
obdata = NULL, right? Another possibility is adding empty obdata of the 
right type to the object, but it doesn't seem nice to leave an unlinked 
object in Blender.

If an object is not linked to a scene and has obdata = NULL, isn't it 
safe to assume that it was created by mistake via bpy and to get rid of 
it in the bpy deallocator (again, if we're confident that it's always 
called)?

-- 
Willian