param
param copied to clipboard
holoviz
Sort parameters in the docstring of Parameter by relevance or alphabetically.
If I run
import panel as pn
print(pn.widgets.DateRangeSlider.__doc__)
I get
$ python 'test_param_stubgen.py'
params(end=Date, start=Date, step=Number, value_throttled=Tuple, value=Tuple, value_end=Parameter, value_start=Parameter, bar_color=Color, direction=ObjectSelector, orientation=ObjectSelector, show_value=Boolean, tooltips=Boolean, disabled=Boolean, loading=Boolean, align=ClassSelector, aspect_ratio=Parameter, background=Parameter, css_classes=List, height=Integer, height_policy=ObjectSelector, margin=Parameter, max_height=Integer, max_width=Integer, min_height=Integer, min_width=Integer, sizing_mode=ObjectSelector, visible=Boolean, width=Integer, width_policy=ObjectSelector, name=String)
Parameters of 'DateRangeSlider'
===============================
Parameters changed from their default values are marked in red.
Soft bound values are marked in cyan.
C/V= Constant/Variable, RO/RW = ReadOnly/ReadWrite, AN=Allow None
Name Value Type Bounds Mode
align 'start' ClassSelector V RW
aspect_ratio None Parameter V RW AN
background None Parameter V RW AN
css_classes None List (0, None) V RW AN
width None Integer (0, None) V RW AN
height None Integer (0, None) V RW AN
min_width None Integer (0, None) V RW AN
min_height None Integer (0, None) V RW AN
max_width None Integer (0, None) V RW AN
max_height None Integer (0, None) V RW AN
margin (5, 10) Parameter V RW
width_policy 'auto' ObjectSelector V RW
height_policy 'auto' ObjectSelector V RW
sizing_mode None ObjectSelector V RW
visible True Boolean (0, 1) V RW
loading False Boolean (0, 1) V RW
disabled False Boolean (0, 1) V RW
bar_color '#e6e6e6' Color V RW
direction 'ltr' ObjectSelector V RW
orientation 'horizontal' ObjectSelector V RW
show_value True Boolean (0, 1) V RW
tooltips True Boolean (0, 1) V RW
value (None, None) Tuple V RW
value_start None Date C RO AN
value_end None Date C RO AN
value_throttled None Tuple C RW AN
start None Date V RW AN
end None Date V RW AN
step 1 Number V RW
Parameter docstrings:
=====================
align: Whether the object should be aligned with the start, end or
center of its container. If set as a tuple it will declare
(vertical, horizontal) alignment.
aspect_ratio: Describes the proportional relationship between component's
width and height. This works if any of component's dimensions
are flexible in size. If set to a number, ``width / height =
aspect_ratio`` relationship will be maintained. Otherwise, if
set to ``"auto"``, component's preferred width and height will
be used to determine the aspect (if not set, no aspect will be
preserved).
background: Background color of the component.
css_classes: CSS classes to apply to the layout.
width: The width of the component (in pixels). This can be either
fixed or preferred width, depending on width sizing policy.
height: The height of the component (in pixels). This can be either
fixed or preferred height, depending on height sizing policy.
min_width: Minimal width of the component (in pixels) if width is adjustable.
min_height: Minimal height of the component (in pixels) if height is adjustable.
max_width: Minimal width of the component (in pixels) if width is adjustable.
max_height: Minimal height of the component (in pixels) if height is adjustable.
margin: Allows to create additional space around the component. May
be specified as a two-tuple of the form (vertical, horizontal)
or a four-tuple (top, right, bottom, left).
width_policy: Describes how the component should maintain its width.
``"auto"``
Use component's preferred sizing policy.
``"fixed"``
Use exactly ``width`` pixels. Component will overflow if
it can't fit in the available horizontal space.
``"fit"``
Use component's preferred width (if set) and allow it to
fit into the available horizontal space within the minimum
and maximum width bounds (if set). Component's width
neither will be aggressively minimized nor maximized.
``"min"``
Use as little horizontal space as possible, not less than
the minimum width (if set). The starting point is the
preferred width (if set). The width of the component may
shrink or grow depending on the parent layout, aspect
management and other factors.
``"max"``
Use as much horizontal space as possible, not more than
the maximum width (if set). The starting point is the
preferred width (if set). The width of the component may
shrink or grow depending on the parent layout, aspect
management and other factors.
height_policy: Describes how the component should maintain its height.
``"auto"``
Use component's preferred sizing policy.
``"fixed"``
Use exactly ``height`` pixels. Component will overflow if
it can't fit in the available vertical space.
``"fit"``
Use component's preferred height (if set) and allow to fit
into the available vertical space within the minimum and
maximum height bounds (if set). Component's height neither
will be aggressively minimized nor maximized.
``"min"``
Use as little vertical space as possible, not less than
the minimum height (if set). The starting point is the
preferred height (if set). The height of the component may
shrink or grow depending on the parent layout, aspect
management and other factors.
``"max"``
Use as much vertical space as possible, not more than the
maximum height (if set). The starting point is the
preferred height (if set). The height of the component may
shrink or grow depending on the parent layout, aspect
management and other factors.
sizing_mode: How the component should size itself.
This is a high-level setting for maintaining width and height
of the component. To gain more fine grained control over
sizing, use ``width_policy``, ``height_policy`` and
``aspect_ratio`` instead (those take precedence over
``sizing_mode``).
``"fixed"``
Component is not responsive. It will retain its original
width and height regardless of any subsequent browser
window resize events.
``"stretch_width"``
Component will responsively resize to stretch to the
available width, without maintaining any aspect ratio. The
height of the component depends on the type of the
component and may be fixed or fit to component's contents.
``"stretch_height"``
Component will responsively resize to stretch to the
available height, without maintaining any aspect
ratio. The width of the component depends on the type of
the component and may be fixed or fit to component's
contents.
``"stretch_both"``
Component is completely responsive, independently in width
and height, and will occupy all the available horizontal
and vertical space, even if this changes the aspect ratio
of the component.
``"scale_width"``
Component will responsively resize to stretch to the
available width, while maintaining the original or
provided aspect ratio.
``"scale_height"``
Component will responsively resize to stretch to the
available height, while maintaining the original or
provided aspect ratio.
``"scale_both"``
Component will responsively resize to both the available
width and height, while maintaining the original or
provided aspect ratio.
visible: Whether the component is visible. Setting visible to false will
hide the component entirely.
loading: Whether or not the Viewable is loading. If True a loading spinner
is shown on top of the Viewable.
disabled: Whether the widget is disabled.
bar_color: Color of the slider bar as a hexidecimal RGB value.
direction: Whether the slider should go from left-to-right ('ltr') or
right-to-left ('rtl')
orientation: Whether the slider should be oriented horizontally or
vertically.
show_value: Whether to show the widget value.
tooltips: Whether the slider handle should display tooltips.
value: < No docstring available >
value_start: < No docstring available >
value_end: < No docstring available >
value_throttled: < No docstring available >
start: < No docstring available >
end: < No docstring available >
step: < No docstring available >
This mean I have to scroll to the end of the table and parameter list to find the most relevant parameters like value, start, end, step.
This makes using Parameterized classes in the HoloViz ecosystem more overwhelming than it has to be.
Solution 1: Sort by Relevance
Reverse the sort. This would make sure what I need most of the time pops up first.
For example something like
def _sorted_parameter_names(parameterized: Type[param.Parameterized]) -> str:
"Returns a list of parameter names sorted by 'relevance'. Most relevant parameters first."
parameters = []
for class_ in reversed(parameterized.mro()):
if issubclass(class_, param.Parameterized):
for parameter in reversed(list(class_.param)):
if not parameter in parameters:
parameters.append(parameter)
return list(reversed(parameters))
could used as a starting point.
Solution 2: Sort alphabetically
This way its easier to search for something specific.
I'd support this change, but I don't know which to prefer. That's because I don't recall what order they come in now; is it determined by the order in the inheritance hierarchy? If so then reversing it may well be a good idea so that the focus is on this specific subclass, not things shared with all subclasses.
Right now what is added to the top most parent class first is the one shown first in the list. Maybe a precedence will override this. But precendence is seldom used in Panel.
In that case I do support reversing the list, plus (if you like) offer a global option to sort them alphabetically.