param
param copied to clipboard
holoviz
Extend ObjectSelector to store a single obj dict
Alternative to https://github.com/holoviz/param/pull/440. This version stores the objects for ObjectSelector and its subclasses as a string->obj dictionary in all cases, which makes the logic cleaner and easier but may not be able to be made backwards compatible.
Updated to provide backwards compatibility in certain ways. With this PR, people should be able to use .objects freely as a dictionary, adding items to it or entirely replacing it with a string->object dictionary of the same type accepted in the constructor. This approach should be backwards compatible with the previously required workarounds mentioned in #331 and #398, in that if self.objects is set to a list and self.names is set to a dictionary, the names set in self.names will be used for the objects. I.e., I think this approach gives good behavior for the future, while also supporting previous usage. Examples:
Note that the type of self.objects is now always an OrderedDict, whereas before it was a list. It still works to set it to a list (via special handling in the property), but I think it's important to return it as a dict so that people can use it naturally. So there's a limitation to the backwards compatibility this PR can support -- anything that was accessing p.objects directly and treating it as a list will now need to access list(p.objects.values()) instead.
@philippjfr, can you please think about the backwards compatibility issues involved, particularly for Panel users, and see if they are manageable? I assume Panel's internal code would need a bit of updating, but that's up to us, whereas user code is what I'm worried about.
If we really needed to support full usage as a list, I guess we'd need to add another property e.g. ".objs" that is a dictionary, then leave ".objects" as a list, and set up all the properties to convert between objects and lists as needed. That seems doable, but would be a pain and makes our own code more complex, so it would be nice if we can avoid that.
Coverage decreased (-0.06%) to 79.414% when pulling 8efa718a292b23b88195a8b60f150c40cfe6c1cb on selectorobjdict into f68fffc86ceba699cbe5d2acf68aed8dfb1626ef on master.
This will be a major backwards compatibility breakage that I expect to affect a lot of people, not just Panel internally but we have plenty of examples iterating over .objects and users will have example updating .objects. I do think it's the right thing to do but I don't quite know on what the migration plan might be.
Is there anything we can do to smooth over any of the backwards compatibility issues?