[Bf-committers] Python RNA Type Registration

[Campbell Barton]

While I think Martins patch is clever and simplifies scripts Im not
comfortable to accept it.

To summarize there are 2 main reasons.
1) it makes registration harder to track, existing bugs in
registration harder to fix.
2) registration needs to be managed externally, by a loader which
collects and registers classes.

At the moment there are bugs with class registration which I have
spent a lot of time trying to fix, only able to resolve some of the
problems.
- reloading classes leaks memory (hold F8 and watch the system ram)
- registering rigify panel manages to insert items into file selectors
operator file list collection. (looks very odd to see rig options
appear in output for link library)
- properties are currently not freed when a class is unregistered,
maybe not hard to fix but needs to be fixed.
- Frequent memory leaks with ID properties and wmReportList on exit
after using python operators.

None of these bugs are show stoppers but I think they need to be fixed
and could become problems once people start writing really involved
scripts (full renderman integration for eg).

RNA class registration is very difficult to debug, not sure its useful
going into details here but it involved tracking problems with python
garbage collection, managing who owns the PyObjects, properly freeing
PyObject and Blenders RNA & the classes properties.
Then trying to deal with this when we have classes re-registering
correctly removing the old classes and adding the new ones in (when
scripts are reloaded).
*sigh*

So I feel a bit of a dictator here to outright reject the patch but as
Ill most likely have to fix these bugs and deal with trouble shooting
problems in this area... its my decision.

 --- some other points listed below though these are more details ---

Some other points...

*** the current register is atomic, useful for Add-ons. The module
manages everything its self, its very clear to the script author whats
happening (while overly verbose).

 import foo
 foo.register() # <-- adds in all menu items and panels etc.
 foo.unregister() # <-- removes its self from blender


(alternative, theeths suggestion could look like this)
 bpy.utils.register_module("foo")
 bpy.utils.unregister_module("foo")

This is OK but not clear for the script author what is registered and
when, simple examples trouble shooting is no problem but imagine a
module that is a package containing 10+ files all containing classes.
debugging problems here I think could become very hard and unclear
what is happening especially with parts of the package importing
classes from elsewhere which module registers the class first... eek!


*** we could have an alternative to verbose registration which can
match what the existing system does.
Rather then use metaclasses we could have a utility class, it could be
done with one line at the bottom of the module.

 from auto_register import register, unregister

...This would have the functions inspect the namespace of the caller,
probably bad design but convenient and at least can be used per-script
rather then forcing all classes to rely on an external mechanism for
registration.

---

For now I prefer to postpone a decision on this, Id also be interested
in seeing how other application handles this and have experienced
python devs give feedback.


On Sun, Feb 28, 2010 at 8:06 PM, Roger Wickes <rogerwickes at yahoo.com> wrote:
> sounds awesome to me!
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell