[Bf-python] Thought about IRC meeting and beyond

[Willian Padovani Germano]

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.

> 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.

> 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.

> 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."

> 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.

> 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()

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.

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.

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.

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