[Bf-python] some suggestions for bpy

[Theo de Ridder]

> From: Campbell Barton <cbarton at metavr.com>
> Date: 21 oktober 2007 0:02:01 GMT+02:00
> To: Blender Foundation Python list <bf-python at blender.org>
> Subject: Re: [Bf-python] some suggestions for bpy
> Reply-To: Blender Foundation Python list <bf-python at blender.org>
>
>
> Hi Theo, thanks for the review. Can I forward this to the python  
> mailing
> list?
>
> A chance for more people to discuss can be good.

no problem if you think its worthwhile

> On Wed, 2007-10-17 at 12:02 +0200, Theo de Ridder wrote:
>> Inspired by many discussions during the Blender conference I thougth
>> a little
>> about what would make bpy a lot closer to what I prefer without
>> changing its
>> basic concepts. So here some first ideas.
>>
>> - bpy.data
>> 	'data' is a word that is very overloaded in Blender, I would suggest
>> to use 'blocks' instead,
>> 	its a plural, close to LibBlockSeq, and much less confusing than
>> 'data'.
>
> This sounds good, I never really liked any of the terms we looked at,
> datablock is more correct, but I prefer to keep the names short.

same for me
>
>> - bpy.data.scenes, bpy.data.meshes, ...
>> 	all deliver the same type (reflecting C), but why not have subtypes
>> of LibBlockSeq ?
> Agree, this is good. When I wrote this I didnt know how to write
> subtypes, youll see in the new api, all data with an ID is a  
> subtype. so
> variables like .name, .users .lib, .tag and .properties are all in the
> base type.
>
>>
>> - bpy.data.<seqname>.new(...)
>> 	'add' would be less confusing than 'new' (or else 'addnew')
>
> Disagree, add() indicates that the arguments passed 'are' the data  
> being
> added.
>
> say for a python set type.
> someset.add(sometuple) # this is correct because sometuple is being
> added to the set.
>
> .addnew() is correct, but Im not fond of the name.
> .new() is short and it indicates that new data is being created, the
> arguments are just parameters.

when 'add' is almost as bad as 'new',  what about 'grow' ?

>> - bpy.data.<seqname>[<str>]
>> 	why not accept also a regular expr as index selecting a subsequence?
>> 	which combined with previous subtype remark enables: bpy.blocks 
>> [<re>]
>> 	(grouping different types by common parts in names)
>
> Not sure, sounds interesting but I have never seen this used in  
> another
> API.
> At a guess, could this do something like return all objects and groups
> based on pattern matching?
> Can you give an example of how it would be useful?

for example with left and right parts with 'left' and 'right' in the  
name,
or a concept as smart folders in a filesystem;

>> - bpy.blocks.<seqname>.attrs[<attrname>]
>> 	creates an efficient iterator for a specific attribute like 'loc'
>
> This is very cool! however is this was added it might be nice to  
> somehow
> allow the scripter to define their own sets of data. maybe allow this
> sequence type - un-attached to blenders linked lists. though we  
> need to
> be careful with pointers of course!
>
> So agree, but operating on all data is not ideal either,  need a nice
> way to have your own sequence/lists.

well, it could be premodelled like Ipo curves, which also have  
reserved names for
each type;

>> - bpy.blocks.<seqname>.attrs[<attrname>] = <value_sequence>
>> 	efficient assignment of a certain attribute of each element in a seq
>> in 1 assigment
>> 	(without looping in Python)
>
>
> same as above. efficient grouping is great, just need a way to define
> what is being operated on.
>
> Note that we already have this in some areas..
>
> you can do bpy.data.meshes.tag = True
> and mesh.tag = True
>
> object.sel = False
> scene.objects.selected = [] # another example, could also accept
> true/false too.
>
>
> Since the sequence's dont have many attributes themselves, do you  
> think
> having the same attributes on the sequence is acceptable? (as shown
> above)
>
> That IS a bit messy though, so having every attribute accessed as you
> say is good. just a bit more text for the scripter to type.
>
> Many people forget that blender can make heavy use of multiple scenes,
> once you start doing this, operating on bpy.data.objects is not so  
> nice,
> and even risks messing up data in other scenes, especially bad because
> you often dont notice and save over your file with bad data. (This has
> happened to me before)
>
> so this attribute access would need to work for scene.objects too, and
> group.objects would be nice also.
>
>> I will experiment with wrapping these last 2 techniques in numpy, if
>> that works
>> indeed efficiently than what I did now specifically with keyblocks
>> can be applied very generic
>> for any collection.

first experiments resulted in a slightly different and simpler approach,
which is robust and enables wrappping with numpy in a generic way:

I mapped 6 datasequences related to meshes with a getter/setter property
onto writable contiguous memory buffers:

keyblock.buffer
mesh.verts.cobuffer	
mesh.verts.nobuffer
mesh.faces.indexbuffer
mash.faces.colorbuffer
mesh.edges.indexbuffer

the main difference with what I presented at the conference is that  
getters now return buffers
as copies, so no problems with lost pointers anymore (I saw this was  
done with CustomData also);
the user is completey free what to do with (the lifetime of) the  
buffers (my own usage is
exploiting the power of numpy);
the setters control only the actual internal length with the new value;
read and write are implemented with smart memcpy's.

Theo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20071021/1f84d579/attachment.html>