-
-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full support of the style system using DynamicMaps #368
Conversation
Just a thought regarding the excess custom ids.... maybe the custom id/tree could be removed when popped from the cache? Then again, someone could still have a handle on an element that is no longer on the cache. Python does offer the ability to know how many references there are to an object: import sys
sys.getrefcount(object) #-- Returns the reference count of the object. Maybe we could use this to implement a system to garbage collect the custom trees... |
I'm just brainstorming here but there is another approach to clean-up the custom trees. This is probably very over-engineered but I'm just trying to come up with ideas!
This would solve the duplicate option trees but there is no reason the list of integer ids wouldn't be able to grow without limit. This could only be solved by sweeping the namespace for all HoloViews objects, and checking with ids actually are being used (then cleaning up the trees associated with the ones no longer in use). Technically possible (using Edit 1: This suggestion is really equivalent to storing the 'inverted' dictionary where the trees are keys (assuming they are hashable, which I think they are) with lists of ids as values which you keep updated. Then it is all about doing the lookup from id to tree... Edit 2: Not quite. Even if a tree is hashable, the hash doesn't really map to its 'value'. You would want each tree to have a unique hash (so you can use them as dictionary keys without restriction) but then you would need to enforce 'uniqueness' of the keys explicitly (making sure the values of all the trees are unique). |
Looks good, glad this could be done fairly easily. The suggestions about squashing the OptionsTrees probably deserve their own issue. I'm happy to merge this now. |
Sure. I've opened an issue about this above. I think you can go ahead and merge! |
Full support of the style system using DynamicMaps
This PR fixes a major issue with
DynamicMaps
, namely that they did not properly support styling. This is because when aDynamicMap
is created it may contain no elements meaning that there is nothing to propagate anid
to when%%opts
or__call__
is used. In other words, every time a value is returned by the callback, it was too late as styling had already been applied.The approach used here seems to work well but there are things I am not entirely happy with:
__class__.__name__
to check for DynamicMap. I am fairly sure I'll encounter cyclic import issues if I try to importDynamicMap
intooptions.py
.OptionTree
to dictionary format and back to anOptionTree
per frame.Hopefully, I can address these issue but I think this PR is very important for the 1.4.1 release. Styling
DynamicMap
as easily asHoloMap
is crucial!