param icon indicating copy to clipboard operation
param copied to clipboard

xarray parameters

Open poplarShift opened this issue 4 years ago • 5 comments

Implements #381

I'm just putting this here for discussion. The PR would need some tests I imagine.

Questions:

  1. Should we validate the provided default? Currently, param is e.g. ok with param.Number(default=None, bounds=(1, 100)) but will throw an error at param.DataFrame(default=None, rows=(1, 10)).

  2. I've tried to carry over (from DataFrames) the distinction between passing sets or lists into the arguments. This might get confusing though... Opinions?

poplarShift avatar Apr 29 '20 22:04 poplarShift

  1. Should we validate the provided default? Currently, param is e.g. ok with param.Number(default=None, bounds=(1, 100)) but will throw an error at param.DataFrame(default=None, rows=(1, 10)).

Param usually sets allow_None=True if the default is set to None, under the assumption that the Parameterized class author clearly thus intends None to be valid for this Parameter. If param.DataFrame does not do that, I would be happy for such code to be added to param.DataFrame (and to these new classes) to do that; it seems like a reasonable thing to do for the convenience of authors.

  1. I've tried to carry over (from DataFrames) the distinction between passing sets or lists into the arguments. This might get confusing though... Opinions?

I agree that's confusing, and completely did not remember that param.DataFrame acted that way. It's important to be able to make that distinction, and sets vs. list/dict does concisely convey that, but it's mysterious. It might be nice to have a more explicit way of conveying the same information, but I can't easily think of any non-clunky way to do it.

jbednar avatar Apr 30 '20 02:04 jbednar

  1. I've tried to carry over (from DataFrames) the distinction between passing sets or lists into the arguments. This might get confusing though... Opinions?

I agree that's confusing, and completely did not remember that param.DataFrame acted that way. It's important to be able to make that distinction, and sets vs. list/dict does concisely convey that, but it's mysterious. It might be nice to have a more explicit way of conveying the same information, but I can't easily think of any non-clunky way to do it.

Then how about set is for minimal requirements, list is for an exact match, and tuple is not allowed? (For dataframes, tuples mean length constraints on the number of columns/rows, but of course constraining the number of dimensions or data variables on an xarray DataArray does not make much sense.)

I would argue that set is "marked" in the sense that using set is usually a conscientious choice whereas people don't pay much attention using lists or tuples. In that way, we would be making the exact matching the "default" behaviour (if you will), which I would argue is sensible.

A second option would be to introduce explicit boolean flags dims_exact etc. or something similar that convey the same information but I agree that's clunky.

poplarShift avatar Apr 30 '20 13:04 poplarShift

PS: Note that a list columns argument to DataFrame will also check for column order. I don't think that makes much sense for a DataArray, so I would drop that distinction here.

poplarShift avatar Apr 30 '20 14:04 poplarShift

Then how about set is for minimal requirements, list is for an exact match, and tuple is not allowed?

Sounds reasonable to me.

jbednar avatar Apr 30 '20 20:04 jbednar

Just noting that this will need some tests and documentation before being merged.

maximlt avatar Apr 05 '23 09:04 maximlt