constructors (Re: [Bf-python] More Proposed API changes.)

[Campbell Barton]

Joe Eagar wrote:
> Toni Alatalo wrote:
>> >>* A new or casual user has to remember that a slightly different 
>> word is used to make the data and >>another is used to loop on it..
>>
>> i guess this hints what the difference in our thinking is: i want bpy 
>> to be as normal Py as possible, while still making sense within the 
>> Blender architecture. this might be different from what a Blender user 
>> with no other Py experience expects. but still i would not differ from 
>> other py lightly: even people who write simple scripts may have used 
>> Py elsewhere too, like for web pages or games. and usually there 
>> always is a constructor
> The problem with constructors, is they imply independent types.  Nothing 
> in bpy is "independant", nearly everything is part of linked lists.  A 
> constructor of a type should create an independant, garbage-collectable 
> instance of that type.  It shouldn't do other things, like automatically 
> add the instance to
> a linked list.  This is why the iterator.new() stuff is better, it tells 
> the user what's really going on.
> 
> So if a user does, "mesh = bpy.Mesh()", is he going to realize that mesh 
> is automatically added to bpy.meshes?  What will he think, when he 
> realizes it isn't garbaged collected?
> 
> Anyway, just my 2 cents.
> 
> Joe


This is my main point...

however we could make it that python types dont add to the linked list 
by default.

I dont see much use in this tho, it would probably end up in users 
making new data, and
A) getting errors when applying the data (because its not linked)
B) The data could get automatically linked into Blenders listbase, which 
would make it hard for scripters to keep track of what was in or out for 
blenders listbase.

If it was manual, then there is only 1 place the data can ever go.. (a 
scene can only ever be in G.scenes) - removing it and having it only as 
a python object could open a can of worms with user counts.... or trying 
to link objects to a scene that wasnt in G.scenes would be tricky too...

maybe one day blender can have 2+ blends open at once, but for now, data 
outside a linked list is problematic.

overall, I think its a solution looking for a problem.

Were better off accepting blender's data dosnt map into a pythonic API 
as well as it might.