[Bf-committers] Python RNA Type Registration

[Campbell Barton]

some corrections....
re-reading, "Its my decision" comment came out wrong.
I meant its the conclusion I came to, not that I'm the only one who can decide.
but it is difficult to come to a consensus when so few devs know this area.

freeing properties works ok, but re-registering a property with the
same name in an existing class doesnt work.

 bpy.types.Scene.FloatProperty("foo")
 bpy.types.Scene.FloatProperty("foo") # <--- this is ignored. it
should replace the existing  type or raise an error.



On Sun, Feb 28, 2010 at 10:17 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> 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
>



-- 
- Campbell