_setup_dynamic_initializer simplified

[SylvainCorlay]

_setup_dynamic_initializer used to return a boolean on whether there is a dynamic initializer for a given trait. It does not anymore.

Two remarks though:

• instance_init is supposed to correspond to the part or the initialization that depends on the HasTraits instance.
  All of what is currently in the implementation of instance_init for our trait types does not actually depend on obj. It could simply be part of __init__. There is no real reason to keep it there.
• After we move this, the call to _setup_dynamic_initializer could be moved to TraitType.instance_init.

[takluyver]

I dislike this change - it makes the API more stateful, because _set_default_value_at_instance_init() now relies on _setup_dynamic_initializer having been called first. But in #23, you remove this method entirely. The two PRs will conflict - what is the relationship between them?

[SylvainCorlay]

I already rebased the #23 on this PR. Regarding statefulness, _trait_dyn_inits is also used in __get__.

The task of _setup_dynamic_initializer is to set this variable.

[takluyver]

OK, should we just be reviewing #23 as a single unit now?

[SylvainCorlay]

• _setup_dynamic_initializer simplified #28 does not change behavior. It is more of a cosmetic change and could be merge more easily.
• Simplify deferred creation of default values #23 is more involving since it changes how default values are initialized.

[SylvainCorlay]

Thanks for looking at this. I guess I am trying to split things too much into small changes to get them in.

So here is the idea: instance_init is supposed to handle the part of the initialization which may depend on the underlying HasTraits instance. What _setup_dynamic_initializer does falls very much into that category. Therefore, it should probably be called in instance_init.

One issue is that instance_init is also called by descriptors holding other descriptors like List(Int()), and we don't want these to be set up by dynamic initializers... Hence there should maybe be two levels for such initialization: one called at the top level only, i.e. called in HasTraits.__new__, which does things like setting default initializers and calls the other one that only does the part necessary for sub-traits.

[takluyver]

As mentioned on #23, I'm not happy about a simplification PR that adds a new public API method. From the diff, this does not now appear to make the code simpler - has what you're trying to achieve changed?

[SylvainCorlay]

Too me, having if isinstance statements is a sign of bad design. It makes sense in the context of metaclass magics, but here it is better solved and more extensible with polymorphism.