Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #807. Makes _update_state from #794 aware of list-type defaults so that it adds the items on the list to the objects, not the entire default value as a sublist. This change does seem to be successful, avoiding
objects=1, 2, 3, [1, 2]]
:Regarding the discussion in #807:
After looking into it I agree. We definitely shouldn't do any extra work to make this code legal:
If people wanted 3 on the objects list, they should have put it there, since they supplied an objects list. This code is currently accepted by this PR, yielding
p.params.objects=[1, 2, 3]
, but if it weren't, I'd be equally happy.Less clear is what should happen when no objects list is supplied:
In this case, it does seem appropriate to be adding the default value to the objects list, and supporting this case automatically makes the above less-important case work.
The way it works still depends on Maxime's _update_state approach, which I can now appreciate. I had previously suggested trying to eliminate _update_state, but the problem (of which I'm sure @maximlt is aware) is that using the Sentinel approach for slot values means that the _objects list doesn't get a concrete value until after the constructor completes and returns control to the metaclass. By that point it's too late for the constructor to add items to the list based on the default, hence needing a new _update_state method to fill it in later.
So if we want to eliminate _update_state (which is a worthwhile goal), I think we'd have to require the objects list to include the default value, which seems like a big disruption to previous usage. If Panel developers are ok with that, sure, but otherwise I guess we are stuck with _update_state.