Skip to content
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

Keyword completion in options #2485

Closed
jlstevens opened this issue Mar 27, 2018 · 9 comments
Closed

Keyword completion in options #2485

jlstevens opened this issue Mar 27, 2018 · 9 comments
Assignees
Milestone

Comments

@jlstevens
Copy link
Contributor

Given that we want to reduce the use of the %%opts magic, it would be good if the .options method could tab-complete the available keywords.

This is possible to do in IPython but it will involve some hackish dynamic updates of docstrings. I'm wondering if this could be done by a safe utility in the constructor, ideally in one place at the Dimensioned level...

@jlstevens
Copy link
Contributor Author

I'll assign this to 1.10 as it would be nice to have a replacement for %%opts that can be recommended even for notebooks.

@jlstevens jlstevens added this to the v1.10 milestone Mar 27, 2018
@jlstevens jlstevens self-assigned this Mar 27, 2018
@jlstevens jlstevens modified the milestones: v1.10, v1.10.x Apr 7, 2018
@philippjfr
Copy link
Member

An alternative to docstring hackery to make this work would be to replace .options with a property which returns an object which would provides a __call__ method which provides the tab-completion. We could for instance dynamically create a ParameterizedFunction which defines the valid options as parameters.

@jlstevens
Copy link
Contributor Author

Maybe I am misremembering but that approach is essentially piggy-backing off param to set the docstrings for you.

@philippjfr
Copy link
Member

Right, I think that's preferable over re-implementing custom docstring hackery for this particular case, but I'll leave that up to whoever implements this.

@jlstevens
Copy link
Contributor Author

I'm fine with this (and happy to implement it) though if I remember right, you were objecting to callable objects that look like methods at one point. :-)

@philippjfr
Copy link
Member

I'm fine with this (and happy to implement it) though if I remember right, you were objecting to callable objects that look like methods at one point. :-)

No I was objecting to using nested APIs like redim everywhere, obj.options() will appear to work just like any other method, something like obj.options.style() is what I would object to.

@jlstevens
Copy link
Contributor Author

Sure though simply by being parameterized means nested things like obj.options.params() will now exist even if not really part of the holoviews API.

@philippjfr
Copy link
Member

Sure though simply by being parameterized means nested things like obj.options.params() will now exist even if not really part of the holoviews API.

True, not ideal I guess, maybe a custom solution is preferable.

@philippjfr
Copy link
Member

Implemented in #3173

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants