[Bf-committers] Auto-registration in Python

[Martin Poirier]

Hi,

--- On Mon, 11/1/10, Campbell Barton <ideasman42 at gmail.com> wrote:

> But now its become a problem that we have more complicated
> situations
> which I dont think can be handled well automatically...
> 
> 1) registering classes which have properties which are
> themselves are
> rna classes... and so on.

This is an issue also with manual registration.

> 2) registration order in these complex cases is not clear.

Not made better with manual registration. Worse, this means is has to be sorted out by all authors and not by a dependency walker (which would be possible but probably not even needed).

> 3) unregistering these needs to be done in the right order
> or there are problems.

Not different when doing it manually.

> 4) dynamically defined classes/operators are also a case
> where auto-registration becomes more tricky then its worth.

If you're talking about the cases where people were using type() to initialize a class, that's very much overcomplicating things for nothing (even without automatic registration).

> Reloading addons/scripts and all of the above problems IMHO
> mean that
> automatic registration is just not able to deal with this
> well.

No. What it does mean is that the RNA registration and properties system as a whole have problems that we didn't foresee before. Going back to manual registration doesn't solve the issues, it shoves them back in the court of the users.

The thing to do now is to identify what those problems are (regardless of the registration method used: the required order of registration and properties definition stays the same in all cases for example) and, if possible, solve them at the C API level, if not, define as clearly as possible the steps needed to do things properly. Only then can we decide if it's at all possible to keep doing things automatically and if not, what kind of documentations needs to be written to show people how to do it manually.

As an added note, unloading plugins is not something that we are the only ones struggling with. Other software sometimes require you to restart the program to correctly unload a running extension, for example. I'm not saying being about to load/unload stuff consecutively in a single session isn't something that we should try to do, but if it makes everyone's life harder, it's possible to compromise.

> For the most part is works OK but there are still problems.
> simple
> example is bug.
> https://projects.blender.org/tracker/index.php?func=detail&aid=24132&group_id=9&atid=498
> I tried for an hour or so to fix it but its just not easy
> to do with
> the current system.

This is exactly the kind of problem I was talking about before in a reply to Nathan. Manual registration is not going to solve this magically.

The real problem here is that properties registration is decoupled from RNA type definition. That is an issue regardless of whether or not registration is done manually.

One thing that can be tried is having optional initialize() and dispose() class methods in RNATypes. initialize is called after the type is registered (so that it is now a real RNA type) while dispose is called before it is unregistered (so that it is still a valid RNA type).

Going back to that bug tracker entry, this is what it would look like:

-----

class XPlaneObjectSettings(bpy.types.IDPropertyGroup):
    @classmethod
    def initialize(cls):
        bpy.types.Object.xplane = bpy.props.PointerProperty(attr="xplane", type=cls, name="XPlane", description="XPlane Export Settings")    

        cls.exportChildren = bpy.props.BoolProperty(attr="exportChildren",
                                    name="Export Children",
                                    description="Export children of this to X-Plane.",
                                    default = False)

    @classmethod
    def dispose(cls):
        del bpy.types.Object.xplane

-----

Doing things this way also makes the class more self contained (it doesn't depend on outside definitions to work properly).

Moreover, it should be possible to make the dispose() code in this case unneeded if defining properties used a wrapper function that associated the defined properties with the module/rnatype where they are defined (which would also make removing non IDPropertyGroup properties on unregister automatic).

> In simple cases its convenient but for complex cases the
> script author
> has no idea whats going on and ends up needing to read
> blenders
> internal registration code to figure out how to make their
> script work.

How would that be any different with manual registration?

> IMHO this is a case where our API tries to hide inner
> working where it shouldn't.

IMHO, this is a case where we didn't abstract the inner workings of our API enough.

Remember, this is an API we want to have around for a long time. The more we can hide the inner warts of the internal C API, the easier it will be in the long term to fix stuff there without having to pull the rug under people's feet.

> So I'm proposing to remove auto registration, will wait
> until next meeting to decide.

This isn't going to fix the problem. At all.

Having thought about this issue a great deal in the last few days, I'm pretty convinced that taking any decisions right now without having properly identified the problem isn't going to help a iota.

Martin