[Bf-python] Thought about IRC meeting and beyond

[Joseph Gilbert]

Willian Padovani Germano wrote:

> Gilbert, Joseph T. wrote:
>
>> 1) The use of True/False over 1/0:
>
>
> Hi Joseph. Python itself accepts many things as true or false, as 
> discussed previously, but of course we won't go there (we won't accept 
> "" as false for functions that don't even expect a string, etc).
>
> The issue with Py_True and Py_False is that using them in our C code 
> causes compile warnings. It's a known py issue. Using our wrappers 
> EXPP_incr_ret_True()/False() (increment and return true or false) we 
> avoid that. It's good to use these wrappers even if we end up using 
> Py_True/False, because then the warnings will appear at a single file, 
> not spread everywhere.


?? Really. This sounds bizzare. There was an issue use PyBoolean_Check() 
or something that was resolved recently by adding the typeobject to the 
.def file for cygwin. Sounds like stivs and yourself are in agreement 
then about using whatever python dictates as 'True' instead of 
restricting to True/False. However python does accept "hello" as true. 
What about this case?

>
>> 2)Constants should be defined in the Module as PyObjects and wrapped by
>> the code in constant.c:
>
>
> One thing to check is if we shouldn't use a Python constant dict 
> instead of constant.c. When that was created Python didn't have a 
> constant dict type, but since 2.2 it has this (not sure it'll work for 
> our needs, we gotta test):
>
> PyObject* PyDictProxy_New(PyObject *dict)
>     Return value: New reference.
>     Return a proxy object for a mapping which enforces read-only 
> behavior. This is normally used to create a proxy to prevent 
> modification of the dictionary for non-dynamic class types. New in 
> version 2.2.
>
> link: http://docs.python.org/api/dictObjects.html#l2h-611
>
> OTOH, bpy constants are nice objects that can be accessed like dict 
> items: mydict['key'] or as mydict.key, so it wouldn't be bad to keep 
> using them.


This is another point. We are talking 2 different types of constants. 
I'm using Module.Constant as a py object, there is another type of 
constant, like the ones in Texture.c which is a dictionary of integers. 
I prefer using pyObject for a number of reasons over the use of 
dictionary constants.  Do we want to have both operate in parallel?

>
>> The result should be individual constant object in the module such as:
>> Module.CONSTANT1, Module.CONSTANT2.
>> Constants should be named with module conventions to avoid import
>> conflicts. I was thinking Module.MDL_CONSTANT1. e.g.
>> Blender.Armature.ARM_LOCX, Blender.Mesh.MSH_LOCX.
>
>
> Yep, maybe like Lamp.LampTypes, Window.WindowTypes, etc.


Again LampTypes is a dictionary. I was thinking breaking out the 
dictionary into individual pyObjects for the module.

>
>> 3)Remove Types.c and place objects in their respective modules using
>> Py_TypeReady() and including the object as a PyObject to the Module
>> dictionary.
>
>
> From what I recall, that file was needed because Windows compilers 
> failed with type initialization in the struct itself. And it also 
> served to solve a nasty crash. For the new api we should test if our 
> workarounds are still needed.
>
> The comment in that file (Types.c) about void types_InitAll( void ):
>
> "The internal types (lowercase first letter, like constant_Type) are 
> only set when some object initializes them.  But unless we do it 
> early, we get some easy and unpredictable (varies with platform, even 
> distro) ways to crash Blender.  Some modules also need this early up, 
> so let's generalize and init all our pytypes here."
>

I understand the comment here. If the typeobject's type is not 
initialized prior to calling the typeobject you'll get a crash. However, 
when Blender loads, it recursivley loads all the modules in blender and 
initializes every module's dictionary. The initialization of the 
typeobject would occur in the module and not in types.c when each module 
is called. I guess the advantage here is that if a module fails to load  
the typeobject still loads. However if a module fails to load we have a 
serious bug in the api. :0

>> 7) GC:
>> Do we need to implement GC on our object types? I would say yes for the
>> mathutils types and possibly subobjects like Bone. Not sure about the
>> rest.
>
>
> If we can avoid this we should. Definitely. Blender has its way to 
> track memory, Python also has its refs mechanism, adding even more 
> instead of using what is there doesn't sound nice. Specially with our 
> varied fauna of script types: registered in menus, alt+p, scriptlinks, 
> space handlers, gui scripts that leave callbacks.


There are 3 tp_xxx pointers and a flag for python GC to allow the 
interpreter to collect circular refs. This is not a good idea then? kk.

>
>> 8) OOP interfaces:
>
>
> The cleanest way imo is to sanitize wherever we can.
>
> An example: we've had trouble (mem leakage) with objects that the user 
> can create and leave without linking to Blender, like bones, etc. We 
> can  prevent that if we simply don't let users create dangling stuff:
>
> # is bad if this something can cause mem leakage:
> mysomething = Something.New() # or = Something()
>
> # is safe, it is created already linked to its Blender container:
> mysomething = containerObject.NewSomething() # or .Something()


Right this was my comment about using factory functions to generate 
subobjects instead of using tp_init and tp_new.

>
> Ton specifically asked us to give access via objects instead of obdata 
> right before the meeting yesterday. I'll ask him to develop his 
> request a little more to understand it throughly, so we can discuss.
>
> In your example, with returned lists, depending on the case it can be 
> better to return tuples and provide our own .append() or .addItem() 
> method.


Tuples would be good too.  .bones in Armature is my own hand coded 
attempt at a dictionary OOP interface. You can call 
myArmature.bones['bone1'] as an example.

>
> A related issue is what Campbell has pointed a few times: Object.Get() 
> returns all objects in Blender, not just the ones in the current 
> scene. This is bad for exporters, for example. We might simplify 
> things, since getting from current scene is a more common request, and 
> make that the default: .Get(fromAllScenes = False) or something like 
> that.


As another related item: Can we deep6 Blender.Get() ? lol

>
> PS: it was agreed yesterday that we should use the wiki for our new 
> api discussions. Personally I think it's better (faster, cleaner) to 
> use this list for the chatting stages, like this reply, but ok, wiki 
> pages are better to organize all discussions and conclusions.


I like the ML for hammering out discussions. :0

>
> Stephen: please explain to us your idea about this project's wiki 
> "layout": where we discuss (single page, per topic), etc.
>
> http://mediawiki.blender.org/index.php/BPy_API_Cleanup_-_2006
>
> -- 
> Willian
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python