-
Notifications
You must be signed in to change notification settings - Fork 766
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
docstrings for new introduced methods regarding params and selection_* #2692
Comments
I agree this should be more informative. I see that there are a couple of TODOs in that file on improving the docstrings for the parameters and for the bindings. Maybe we can use the same I approach I used #1629 to overwrite the docstring of On a related note, is there any use to keep having |
Is it possible some of these issues have been incidentally fixed along the way? For example, I seem to have docstrings showing up okay. shift+tab also seems to reveal a docstring (I can't get a screenshot at the moment). A different issue is that these are the docstrings for the lower-level objects, such as Before looking into this further, I wanted to check @mattijn to what extent the issue you reported in October has been resolved. Thanks! |
@joelostblom I agree it could make sense to hide |
You are right! This is fixed along the way. Great. If you want to hide the @utils.deprecation.deprecated(
message="'selection' is deprecated. Use xxx"
)
def selection(type=Undefined, **kwds): |
Hm, not sure. This is the current docstring for def param(name=None, select=None, **kwds):
"""Create a named parameter.
Parameters
----------
name : string (optional)
The name of the parameter. If not specified, a unique name will be
created.
**kwds :
additional keywords will be used to construct a parameter. If 'select'
is among the keywords, then a SelectionParameter will be created.
Otherwise, a VariableParameter will be created.
Returns
-------
parameter: Parameter
The parameter object that can be used in chart creation.
""" I would say that is too limited to consider this issue complete. |
Glad the docstrings also working on your end @mattijn! The displayed signature isn't perfect, because on the Altair side we allow a parameter and its selection configuration to be defined simultaneously, but the above docstring only mentions the selection portion. For example, I believe all of these are missing from I agree that we should keep this issue open for now. |
Hi @mattijn, I will try to improve the parameter docstrings. Is there anything wrong with just typing it out by hand in VS Code, including for example the valid keyword arguments? I just want to make sure that's reasonable before getting started. Getting the valid arguments automatically from Vega-Lite is harder than usual for parameters, because on the Vega-Lite side, there is a parameter definition like this
but on the Altair side, those values of |
By hand is fine. |
Is there a rule of thumb for when |
In the context of Altair, |
Currently the docstrings for some new introduced parameter methods are rather limited:
Where in the above example I've defined it as such:
How can one know about this without docstrings?
The text was updated successfully, but these errors were encountered: