[Bf-committers] Python RNA Type Registration

Campbell Barton ideasman42 at gmail.com
Mon Mar 1 09:02:54 CET 2010


one thing I forgot to mention is:
How do we keep Alt+P running scripts in the text editor, register it
looks like this...

... script body ...

def register():
    ....
def unregister()
   ....
if __name__ == "__main__":
   register()


Its nice to be able to open a script in the text editor, press "Run"
and see the updates immediate.
I really prefer we don't drop this.

Bringing this up because your method relies on setting a context and
collecting classes from an external module, is there some way to allow
direct execution to register also?

reply to your other points inline...

On Mon, Mar 1, 2010 at 3:22 AM, Martin Poirier <theeth at yahoo.com> wrote:
> I've been talking it over with Campbell on IRC. Here's what came out (more or less).
>
> --- On Sun, 2/28/10, Campbell Barton <ideasman42 at gmail.com> wrote:
>
>> To summarize there are 2 main reasons.
>> 1) it makes registration harder to track, existing bugs in
>> registration harder to fix.
>
> Metaclass registration actually makes it easier to debug.
>
> There's some debugging code (part commented in the patch, part removed) that printed out the whole class creation order (listed by module) as well as their registration order, so if something fails, you know exactly where you are and what happened before.

Glad this is added, but I'm not totally convinced, read on.

>> 2) registration needs to be managed externally, by a loader
>> which
>> collects and registers classes.
>
> Modules are already loaded externally with a loader in utils.py, that you wrote.
>
> This isn't added complexity, if anything, it centralizes it instead or relying on module authors to write their own.

Technically they are loaded by an external loader but all it does is
import and run the register function, which will give errors in the
authors code. also makes running script call register very easy,
something Im not sure about with your patch (as stated above).

>> 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).
>
> One thing they also have in common is that none of these bugs have anything to do with the registration method used and that applying the proposed change doesn't make any of that harder to debug.
>
> I agree that these are serious issues, but I don't think they have much to do with the question at hand (it's not like I was asking people to do extra work, the patch already exists and it simplifies further work).
>
> Also, not long ago, I went over a bug caused by how the current registration method is used on custom IDPropertyGroups, it's a bit complex to explain (and out of scope here), but metaclass registration also makes it easier to solve.

yes & no, they do have something to do with the registration method in
that when trying to fix the bugs you must understand whats going on
with registering pretty well. (what order, whats registered, double
registered, whats freed etc)
But your right in that its not directly related, I say this more to
show the current system is not in control so Im not happy to add code
that confuses me more if I have to spend a lot of time debugging.

>>  --- 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")
>
> In reality, I haven't suggested anything because I find the use case completely void. Scripts shouldn't be registering other modules, it will make just everything harder to track. If we *absolutely* need to support this, it can be done with code injection (adding the automatic registration calls to the register() and unregister() methods of the modules).
>
> On the other hand, if we have to track dependencies, it should be done by an api function, not by script authors managing it themselves (this could probably be done transparently with an import hook).

for users no, but its not uncommon to reload scripts while testing (I
did this last week for fixing the BVH importer).

>> 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!
>
> NetRender already does that, there hasn't been many issues (off hand, I recall the last problem was when the explicit registration system started being used)
>
>> *** 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.
>
> Inspecting the namespace is nasty and has so many corner cases, I can't believe you think it would be actually better.

yep, its not pretty, but an option to keep in mind.

>> 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.
>
> Maya has automatic registration based on matching filenames with node names and specific prefixes as well as explicit registration (mostly for C++ addons).
>
> I don't think looking at other 3D software is such a good idea, there's a crap load of bad practice out there.

notice I didn't say other 3D software :), already looked into this and
was pretty shocked at the quality of their pyAPI's.

> Martin
>
>
>      __________________________________________________________________
> The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list