TraitType init_instance should be able to depend on object initialization arguments

[NeilGirdhar]

I am trying to replace my traitlet-like system with the traitlets project. I have a number of "Cluster" objects that have a size member, which is provided to the constructor. They contain numpy array traits that should be sized according to this size:

    class ClusterSizedNDArray(NDArray):

        def __init__(self, **metadata):
            super().__init__(cluster_sized=True,
                             shape=(),
                             dtype=np.float64,
                             **metadata)

        def shape(self, obj):
            return (obj.size,) + self.metadata['shape']


    class Cluster(HasTraits):

        signals = ClusterSizedNDArray()

        def __new__(cls, *args, **kw):
            new_meth = super().__new__
            size = kw.pop('size')
            obj = new_meth(cls, **kw)
            # Initialize size before traits are populated that have that size.
            obj.size = size
            return obj

Unfortunately, this doesn't work because obj.size is still not set on the object until after HasTraits.__new__ has been called. What would be a nice way to make this work? Is this something that traitlets can handle or should I implement my own similar system?

Perhaps I should inherit from another class that just sets the size, so that the mro is Cluster, HasTraits, SizeSettingBaseClass?

[rmorshea]

This is being looked at right now in #70. The current plan is to introduce an install_descriptors hook that can be overwritten to add obj attributes that are required to run instance_init.

[NeilGirdhar]

@rmorshea I don't see how install_descriptors solves my problem? I've merged Sylvain's recent pull request into my code, and I can't seem to figure out how to initialize the size on the object. The size is passed in the arguments to the constructor. init_instance is called from __new__. If HasTraits are at the top of the MRO, the child classes won't have a change to install the attribute in their __new__. Overriding install_descriptors would work if there were a default size or something, but I need to initialize it to a passed-in value.

[rmorshea]

Is size a static attribute?

[rmorshea]

Also it seems odd that the function shape exists on the TraitType. Unless that's used to initialize a value on the TraitType, it should probably be associated with the value of that attribute instead because TraitTypes are set on HasTraits classes rather than instances. I may be misunderstanding the application, but it seems that the obj should be provided to the value rather than the TraitType, which means this should be something that's handled upon setting signal.

[NeilGirdhar]

@rmorshea : size is passed to the constructor of the object (the HasTraits instance). The reason shape exists on TraitType is so that the NDArray class can create an array of the right size. The problem is getting shape to answer correctly. I don't understand your last sentence probably because I don't understand traitlets well enough.

[rmorshea]

Ok, this is a case where you'd want to use dynamic defaults:

old api - _'name'_default
new api (#76) @default

[NeilGirdhar]

@rmorshea If this works, it looks like you guys have thought of everything. What connects the x default to the trait i?

[rmorshea]

In the old api, and using your case, to create a dynamic default generator for the trait signal you would define a method _signal_default(self) on the HasTraits instance which returned the desired value.

This method is not called when creating the instance though. Instead it is called the first time the trait is accessed iff no value has already been set (see TraitType._dynamic_default_callable).

[NeilGirdhar]

@rmorshea Yes, thanks, just figuring it out now. Looking forward to your pull request being accepted. FYI I think your pull request should have x = Int() —not i = Int() in the first comment.

[rmorshea]

Thanks, glad I could help.
On Thu, Sep 24, 2015 at 8:12 PM Neil notifications@github.com wrote:

@rmorshea https://github.com/rmorshea Yes, thanks, just figuring it out
now. Looking forward to your pull request being accepted.

—
Reply to this email directly or view it on GitHub
#90 (comment).

[NeilGirdhar]

@rmorshea I really appreciate it!