You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Type hint annotations are rapidly approaching maturity in the Python world, to the point where it is common for functions to provide these for the arguments.
Currently if you have a function with type annotations like:
deff(x: int) ->int:
returnx**2
the interact function and related infrastructure can't infer anything from the annotation of the argument types, so
interact(f)
fails: the user must supply additional information. It seems like it would be reasonable in this situation to use basic type hints (eg. int, float, etc.) to provide a basic Widget for the argument (although maybe not a slider: something like IntText might be better), ie. to have behaviour which is equivalent to
interact(f, x=IntText())
Since interact is fairly basic, it probably only makes sense to support str, int, float, bool, and Enum - anything more complex should be ignored.
Proposed Solution
I think this can be achieved in a fairly straightforward way without changing current working behaviour as follows:
in _yield_abbreviations_for_parameter add an additional branch to this block
add a new method interactive.widget_from_annotation which branches on the type to create appropriate widgets for each supported type. Since there is no value or default supplied, this will use the default value of the widget type (eg. empty string for Text, 0 for IntText, etc.). This might look something like this:
@staticmethoddefwidget_from_annotation(t):
"""Make widgets from type annotation and optional default value."""iftisstr:
returnText()
eliftisbool:
returnCheckbox()
eliftin {int, Integral}:
returnIntText()
eliftin {float, Real}:
returnFloatText()
elifisinstance(t, EnumType):
returnDropdown(options={option.name: optionforoptionint})
else:
returnNone
call this new method from interactive.widget_from_abbrev in this section
Because the annotations are only considered as abbreviations after all other possibilites have failed, existing working code will continue to produce the same results.
Problem
Type hint annotations are rapidly approaching maturity in the Python world, to the point where it is common for functions to provide these for the arguments.
Currently if you have a function with type annotations like:
the
interact
function and related infrastructure can't infer anything from the annotation of the argument types, sofails: the user must supply additional information. It seems like it would be reasonable in this situation to use basic type hints (eg.
int
,float
, etc.) to provide a basic Widget for the argument (although maybe not a slider: something likeIntText
might be better), ie. to have behaviour which is equivalent toSince
interact
is fairly basic, it probably only makes sense to supportstr
,int
,float
,bool
, andEnum
- anything more complex should be ignored.Proposed Solution
I think this can be achieved in a fairly straightforward way without changing current working behaviour as follows:
_yield_abbreviations_for_parameter
add an additional branch to this blockipywidgets/python/ipywidgets/ipywidgets/widgets/interaction.py
Lines 123 to 130 in b78de43
interactive.widget_from_annotation
which branches on the type to create appropriate widgets for each supported type. Since there is no value or default supplied, this will use the default value of the widget type (eg. empty string forText
, 0 forIntText
, etc.). This might look something like this:interactive.widget_from_abbrev
in this sectionipywidgets/python/ipywidgets/ipywidgets/widgets/interaction.py
Lines 298 to 311 in b78de43
Because the annotations are only considered as abbreviations after all other possibilites have failed, existing working code will continue to produce the same results.
Additional context
I have a basic implemention along these lines working in this branch: https://github.com/corranwebster/ipywidgets/tree/feat/interact-type-hints
The text was updated successfully, but these errors were encountered: