I am not sure if this is something that should go into the holoviews issues as a bug report, so I am reporting it here.
The function hv.help does not list the valid option legend_opts. This is similar to colorbar_opts and gridstyle. They all are actually very complex options that take a dictionary of sub-options. Ideally, those sub-options would also be listed in the hv.help documentation.
For example: I don’t see a good way to get a legend title in an overlay of an NdOverlay of curves and an hv.HLine, except for using .opts(legend_opts={'title':'my legend title'}).
Generally, I think the whole system of hv.help is a little cumbersome. Ideally that would be all in the docstring. I personally prefer a really long docstring, instead of having to type something like hv.help(hv.DynamicMap) in a new cell / terminal every time to make sure I don’t miss any options. In that sense Matlab was better. You pressed F1 and a big popup showed up that was like a full blown website with lots of example code and images and lots of text. There I found it totally acceptable if the help documentation was really long.
This is such a fantastic project. I really hope it gets more resources allocated. I never have produced more good looking and functional plots than with this.
I think there’s a limitation here. Some of the options depend on the activated plotting backend (bokeh, matplotlib or plotly). So that’s why it’s very helpful, and required actually, to have a way to dynamically get the options available. Now maybe there’s a number of options that could already be listed in the docstrings. One thing that doesn’t sound fun is that it would mean to duplicate all these options for all the HoloViews elements. Not cool. What Pandas does for instance is link to a page that lists the extra options available, that’s one solution: pandas.DataFrame.plot.line — pandas 1.4.3 documentation
@Jan feel free to open a feature request on HoloViews’ GitHub, if there’s not already one asking for this.
Yeah. I know that some of the styling options depend on the backend. But there are only three backends. One could still list just everything for all three backends. The user generally knows which backend he is using.
Also, I think because everything goes through docstrings in python, people don’t like them very long. Maybe there would be a programmatic way of manipulating all those docstrings at the same time if some base parameter is added or changed.
I have been using Matlab for a long time and i find their approach great. You press F1 and get a very comprehensive and nice looking help pages. Those can be very long and contain pictures and you can fold uninteresting sections. This page for example is the page for a line plot: 2-D line plot - MATLAB plot’
I guess two things would help to get there in python:
Have an editor that is able to fold the docstring, so it’s not so annoyingly long or tugged away completely.
Have a docstring parser that can handle more complex markup, for example something that could handle everything that jupyter notebook markdown cells can do (Pictures, Latex, HTML…). For example the Sphinx docstring parser seems to be able to parse and display images. image - Is it possible embed pictures into docstring in Python? - Stack Overflow
An alternative would be to link to a website that is referenced in the docstring and display that. I guess this is how Matlab does it. Probably those websites then should be accessible offline, if there is no internet connection.
Oh boy! A plotting backend can accept many parameters. Multiplied by 3, that’s in the order of hundreds of parameters.
All your other requests make sense to me. Unfortunately there isn’t much we can do at our level. I’d invite you to open a feature request on Jupyter Lab.
A plotting backend can accept many parameters. Multiplied by 3, that’s in the order of hundreds of parameters.