[Bf-committers] Auto-registration in Python

Nathan Vegdahl cessen at cessen.com
Thu Oct 28 22:34:13 CEST 2010


> It should be even more trivial with automatic registration.

And yet in reality...

Here's the thing: I'm speaking as someone who was not involved in
designing the system.  For someone who doesn't have knowledge of the
internals of how auto-registration works, it becomes a magical system
with semi-unpredictable and unclear rules.  Like, what gets
registered?  What doesn't?  How do I control that so that I can
structure my code how I want to?  When do things get registered?  Etc.

And to make things concrete: it is not obvious, for example, how I
should structure my code so that I don't get weird errors like this
upon enabling an addon a second time: http://www.pasteall.org/16500

(Hint: after randomly trying things with no particular logic, I
discovered that if I move my ID property class definitions into the
register function, some--not all--of these errors go away.  But why
that is?  No idea.  It's not intuitive at all, and therefore a
crap-shoot to solve.  And it's also patently silly that I have to move
those class definitions there at all.)

> It removes a lot of needless boiler plate code

It removes a _trivial_ amount of boiler plate code.  One
register/unregister call per class is not a lot of code.

> as well as the possibility of easier debugging in those cases where
> registration fails and gives a easy way internally to figure out what
> is defined where.

It is still quite easy to find classes with registration problems,
because they are referenced by name in the explicit registration
calls.  If one of my panel classes fails to register, it is not going
to be at all difficult to track down.

Unless I'm misunderstanding what you mean?

> it ensures that every script is a "good citizen" and correctly
> registers and unregisters RNA types when the system needs
> and not when bad code mistakingly does it

Sure, I can see garbage collection parallels, for example.  And I
agree that this is nice.

But what I dislike about it is that it forces the scripter to
structure their code in specific ways (a subset of what python allows,
see your mixin comment for example) that may not be most appropriate
to the problem at hand, or to their preferences.  _And_ more
importantly it introduces a new set of (non-obvious) rules that the
scripter has to be aware of beyond just python itself and the blender
python API.

It really does feel like additional language restrictions.  On top of
mystical magic.

> The rule is that only valid well defined classes should derive from RNA
> types, so if you have common behaviors to define, use mixin classes.

But this is a silly and needless restriction.  At the _very least_, if
we stick with auto-registration we ought to do something like using
decorators to specify what gets registered.  Something like:

@bpy.register
class MyPanel(bpy.types.Panel):
    blah blah blah

At least that way the scripter explicitly knows what is going to get
registered, and can control that.  It would also remove some of the
confusing "magical" feeling of the whole thing, and would allow people
to structure their code as desired/needed.

--Nathan


On Thu, Oct 28, 2010 at 8:25 AM, Martin Poirier <theeth at yahoo.com> wrote:
> Hi Nathan,
>
> --- On Thu, 10/28/10, Nathan Vegdahl <cessen at cessen.com> wrote:
>
>> I think this may be one of those things that is convenient
>> in simple
>> cases, but is just troublesome in complex cases.  For
>> example, I'm
>> still struggling to figure out how to make the Rigify addon
>> unregister
>> cleanly.  Ditto with the porting project I did.
>> It doesn't seem
>> possible.  But it was trivial with manual
>> registration.
>
> It should be even more trivial with automatic registration. The only thing you need to take care of is registered properties, and I'm not even sure if those can be deleted correctly at this point (Campbell could confirm this).
>
> Registered properties is still the biggest pitfall, IMHO, and needs to be addressed. (that doesn't have much to do with automatic registration of RNA types though)
>
>> I would much rather manage the registration and
>> un-registration
>> manually, so I can guarantee that everything works cleanly
>> even in weird corner-cases.
>
> Can you give an example of such a corner case?
>
> Or better yet, when you encounter a problem, please mention it on this list (or to me directly, if you don't want to do it on a public channel) and it will be looked it. The code is certainly not perfect and there's a couple of things to keep in mind when coding that was much free for all before (I see that as a good thing).
>
>> And it makes it difficult (impossible?), for example, to
>> write a class
>> (say, a panel) that is just meant to be inherited from, but
>> not
>> directly registered.
>
> There's some examples of that in the UI scripts (properties_material.py look for the MaterialButtonsPanel class and its subclasses). The rule is that only valid well defined classes should derive from RNA types, so if you have common behaviors to define, use mixin classes.
>
> I actually think it's cleaner this way. When reading code, it's easier to see which classes define behaviors and which are actual RNA types.
>
>> Anyway, just my 2 cents.  I'm finding
>> auto-registration to be a
>> needless headache, for only minor convenience gains in
>> simple cases.
>
> I'm finding the same thing, except in reverse.
>
> It removes a lot of needless boiler plate code, it ensures that every script is a "good citizen" and correctly registers and unregisters RNA types when the system needs and not when bad code mistakingly does it, it transparently enables optional add-ons as well as interactive execution in a text buffer, it gives a single point of entry for registration calls as well as the possibility of easier debugging in those cases where registration fails and gives a easy way internally to figure out what is defined where.
>
> Martin
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list