Closed efenton32 closed 2 years ago
The intention behind using help(FluoSpecModel)
or FluoSpecModel?
instead of hard coding it in a docstring is that the parameters will always reflect what is in the actual code, and thus eliminates the possibility of userspace issues arising from not updating docstrings to reflect new parameters.
If you run help(FluoSpecModel)
, you get something like
class FluoSpecModel(builtins.object)
| FluoSpecModel(A_prior_params: Tuple, w0_prior_params: Tuple, gamma_prior_params: Tuple, intensity_ratio_prior_params: Tuple, m_prior_params: Tuple, b_prior_params: Tuple) -> None
which gives the order of the parameters (and their expected types), or their names if you want to use keyword arguments.
Running FluoSpecModel?
Init signature:
FluoSpecModel(
A_prior_params: Tuple,
w0_prior_params: Tuple,
gamma_prior_params: Tuple,
intensity_ratio_prior_params: Tuple,
m_prior_params: Tuple,
b_prior_params: Tuple,
) -> None
Docstring:
Class for fluospec model. Instantiate with parameters on normal prior, as
tuple with (mean, std)
Run `FluoSpecModel?` to see order.
File: c:\users\brodi\documents\github\fluorescencespectroscopy\fluospec\model.py
Type: type
Subclasses:
Likewise, Init signature
contains the order of the input parameters, or their names for use as kwargs.
You mention running 'FluoSpecModel?' to know the order of parameters in the priors, but you might want to just explicitly state it in the docstring, especially since it's not obvious from how they're passed to the pymc3 model.