add parent to Configurable #3430
Conversation
|
still a few tests to fix |
|
Does this work deeper than two levels like |
|
Does each child still have its own copy of the config data, or does it refer to the parents? |
I don't think so, but perhaps it should. There is another question here - should Foo.Bam configure Bam in the Foo.Bar.Bam case (i.e. any descendent)?
There is no change in who has what data or how many copies. The only change is the optional addition of |
|
I see a failure in |
|
If it is not too difficult to make it work deeper than 2 levels, I think we should do that. In terms of the skipping of descendants, I could imagine usage cases where you would want both behaviors. But maybe we should keep it simple for now and require all classes to be listed. If we run into issues with that approach later, we can change it. We have survived for a few years without this capability so I am not sure exactly how it will be used. |
|
Hey @minrk, it needs a rebase now, and it looks like a bit of work... Do you think you want/have bandwidth to finish this one in the next week? |
|
Sure, should be easy enough. |
this adds the notion of a parent and member config,
so the config:
c.Foo.Bar.attr = value
will only set `Bar.attr = value` for `Bar` instances
which are members of `Foo` instances.
The mechanism for doing this is
```python
f = Foo(config=cfg)
f.b = Bar(parent=f)
```
This Instance config has higher priority than plain class config for Bar,
but still lower priority than direct keyword arg trait assignment.
The main implication this has is to change the standard creation of descendants:
```python
self.bar = Bar(config=self.config)
```
into a direct parent expression
```python
self.bar = Bar(parent=self)
```
This also means that most Configurables will actually have a handle on their parent object.
instead of `config=self.config` only real effective change: IPythonKernelApp.parent has been renamed to IPKernelApp.parent_handle.
now Foo.Bar.Baz can affect a Baz whose parent is Bar whose parent is Foo. More specificity = higher priority, so Foo.Bar.Baz > Bar.Baz > Baz.
Configurables often resolve to zero for some reason
|
rebased, and I also fixed the issue in the MKM test |
|
This looks good, merging. |
add parent to Configurable
this adds the notion of a parent and member config, so the config:
c.Foo.Bar.attr = value
will only set
Bar.attr = valueforBarinstances which are members ofFooinstances. The mechanism for doing this isThis Instance config has higher priority than plain class config for Bar, but still lower priority than direct keyword arg trait assignment.
The main implication this has is to change the standard creation of descendants:
into a direct parent expression
This also means that most Configurables will actually have a handle on their parent object.
It also means that most IPython configurables have a handle on their parent object.
If this is undesirable, we can construct the name list at init, without holding onto the key.