jbednar
commented
6 years ago Strictly speaking, this might end up being implemented using Bokeh widgets directly, and need not necessarily involve ParamBokeh, but my guess is that it would be easier to do it using the lookup tables, etc. we already have in ParamBokeh.
Param and ParamBokeh were designed to support large, complex systems, with hierarchically organized options mirroring a class hierarchy that allows a clean separation between parameters for objects and any widgets that might be appropriate to display when those objects are used in a GUI context. Thus parameters are all currently declared as class attributes of Parameter type, independently of any package like ParamBokeh that will create GUI widgets from those definitions. For complex systems, separating the parameter declaration from the widget instantiation provides major benefits to the code even apart from any widgets, such as type and range checking that helps keep interactions between components manageable.
However, there are other contexts where it would be useful to have Bokeh-based widgets that don't involve complex hierarchical systems, and the class Parameter approach is not necessarily the best approach in those cases. For instance, when using a Jupyter notebook as a command prompt, it's often useful to create a widget explicitly for a particular local task, without designing a class hierarchy. The API from ipywidgets'
interact()function is a good example of this alternative approach, which won't necessarily scale to larger projects, but can be very convenient in a single Jupyter cell or in a very basic dashboard.Mirroring or nearly mirroring the
interact()API specifically would also make it easier for people to switch between ipywidgets and param-based approaches, e.g. to evaluate Bokeh Server as a deployment mechanism. If we provide aninteract()equivalent, we would need to be very clear in the documentation about its purpose, and to make its limitations clear.