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

Miscellaneous fixes to opts validation #3257

Merged
merged 21 commits into from Dec 7, 2018
Merged

Conversation

jlstevens
Copy link
Contributor

Fixes opts.defaults and enables cross-backend validation in the hv.opts completers.

if invalid:
try:
cls._options_error(list(invalid)[0], element,
Store.current_backend, allowed)
cls._options_error(list(invalid)[0], element, None, allowed)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this support passing an explicit backend kwarg? The way it works for .options is that if you pass in a specific backend it becomes completely strict otherwise it's permissive about options which apply to one backend but not another. So if we want to support that you'd pop backend from kws above and then replace None here with the popped backend (defaulting to None).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially I thought it would be trivial to support this but in the end I needed to do a little refactoring in b43f60e to get this working.

@jlstevens
Copy link
Contributor Author

@philippjfr I renamed expand_options to _expand_options: I want to keep the public portion of the opts namespace very clear for users. Any objections?

kwargs['clone'] = clone

if apply_option_types and util.config.future_deprecations:
param.main.warning("Dictionary signature of opts method deprecated. "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This warning does not seem particularly informative, what dictionary format? I'd probably be specific about it and have very specific warnings for each of the three conditions above since I don't think there is a clear way of describing all the nested formats at once.

Copy link
Contributor Author

@jlstevens jlstevens Dec 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm not sure that is really necessary - the warning message points to hv.opts.apply_option_types (not sure about that name!) which would accept whatever signature was supplied with only very minor modification (obj as the first argument). The signature is also described better on the docstring of that method.

In other words, I would expect the only people to see this warning would be people using .opts the old way in which case they should start using hv.opts.apply_option_types and I don't really see why the warning itself needs to go into the details about the signature...

Copy link
Member

@philippjfr philippjfr Dec 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, fair enough, maybe just clarify "dictionary signature" a bit more, something like:

Calling the .opts method with options broken down by options group (i.e. separate plot, style and norm groups) is deprecated. Use the .options method converting to the simplified format instead or use hv.opts.apply_option_types for backward compatibility.

@jlstevens
Copy link
Contributor Author

@philippjfr Ready to review/merge once the tests are green.

@@ -95,6 +95,94 @@ def __call__(self, *args, **params):

self._cellmagic(args[0], args[1])


@classmethod
def option_groups(cls, obj, options=None, backend=None, clone=True, **kwargs):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't want to call this apply_option_groups or similar?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, apply_groups I guess!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in fb81455, thanks.


For backwards compatibility, this method also supports the
option group semantics now offered by the
hv.opts.apply_options_type utility. This usage will be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Called apply_options_type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in fb81455

@philippjfr
Copy link
Member

I haven't looked but aren't there changes needed for subclasses that define an opts method?

@jlstevens
Copy link
Contributor Author

jlstevens commented Dec 6, 2018

I haven't looked but aren't there changes needed for subclasses that define an opts method?

I'll double check that, but I think they all delegate most of the actual work via super.

Edit: You are right, if nothing else the signatures need to be made consistent.

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

Successfully merging this pull request may close these issues.

None yet

2 participants