[Bf-python] Proposed BPyAPI Additions.

[Campbell Barton]

Hey Willian,
I dont think we can stop people from adding new objects while iterating.

I thaught doing somthing like only allowing to add a new object when the 
the pypypes  "iter" value is NULL
would be ok but  it wont work if you break early.


I think the only way it can be done is to use a refcounter on the scene 
that lets python know how many scn.objects  there are iterating (can 
increment on getIter), and only if its 0, let the user add objects.

All up I dont think its the biggest of our problems, but interested to 
see if theres another way to do this.

Willian Padovani Germano wrote:
> 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)?
>


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241