Plan is to have a flat namespace for public functions:
plot_ (plot_forest, plot_autocorrelation, etc)stat_ (not wild about this naming convention - maybe just make sure these names are descriptive and exposed in the top-level namespace. thoughts?)convert_to_xarray, style.use)load_arviz_data to load_datasetmatplotlib.pyplot or xarray are not making it into the arviz namespace.To me it depends on how large this library is going to get.
If its mostly just plotting and plotting utils then I like seaborns approach which is similar to the current api
https://seaborn.pydata.org/api.html
If this package is going to have plotting, and a bunch of utility functions and statistics, then scikit learns nested API is the opposite extreme.
Right now it seems like this package is in the middle, with mostly plotting, but some other functionality built in as well.
If we think people are mostly going to use this package for statistics, perhaps leave those in the top level namespace, and then put stats, utils, diagnostics into its own?
For for example
az.traceplot or az.plot_trace
and for stats
az.stats.summary
Same for utils
az.utils.convert_to_xarray
Hi,
I'm not sure if convert_to_xarray, convert_to_dataset or convert_to_inference_data are best names.
I usually first try from_ and I don't find anything, I try read_ or to_
We could have
az.from_numpy
az.from_stan
az.from_pymc3
az.from_dict
or maybe
az.to_arviz
az.to_dataset # az.to_xarray ?
which would return either arviz.inference_data and xarray_dataset.
My only hesitation with that is that there will be different return types (turning a numpy array into inference data is a _ton_ of guessing about intentions). What about exposing
to_inference_data
to_dataset
from_pymc3
from_stan
in the top level, and rename the directory to convert, so you can az.convert.dict_to_dataset or az.convert.numpy_to_dataarray if you need extra specificity.
I know it is not consistent, but I sort of like that from_pymc3 accepts a trace argument, while from_stan accepts a fit object, which will be familiar to users of the library. Hopefully from_pyro and from_tfp will show up soon!
Sorry for asking stupid questions, I was quite busy at work lately and could not follow the discussions as closely as I would have liked. Is the idea mainly to republish things that are currently in submodules in the main namespace, as in:
# arviz/__init__.py
from arviz.plots.forestplot import plot_forest
or is this about actually moving the submodules into toplevel namespace?
It has ended up being a little bit of both!
utils.py and xarray_utils.py, whose functions are now in the data directoryplots directory still exists, and the files have the same names, but the plot function names are all changed (I think this is what you meant by republish)The output of tree is below, in case that's helpful.
โ arviz (master) tree .
.
โโโ data
โย ย โโโ base.py
โย ย โโโ converters.py
โย ย โโโ _datasets
โย ย โย ย โโโ centered_eight.nc
โย ย โย ย โโโ non_centered_eight.nc
โย ย โย ย โโโ radon.nc
โย ย โโโ inference_data.py
โย ย โโโ __init__.py
โย ย โโโ io_netcdf.py
โย ย โโโ io_pymc3.py
โย ย โโโ io_pystan.py
โโโ __init__.py
โโโ plots
โย ย โโโ autocorrplot.py
โย ย โโโ compareplot.py
โย ย โโโ densityplot.py
โย ย โโโ energyplot.py
โย ย โโโ forestplot.py
โย ย โโโ __init__.py
โย ย โโโ jointplot.py
โย ย โโโ kdeplot.py
โย ย โโโ khatplot.py
โย ย โโโ pairplot.py
โย ย โโโ parallelplot.py
โย ย โโโ plot_utils.py
โย ย โโโ posteriorplot.py
โย ย โโโ ppcplot.py
โย ย โโโ styles
โย ย โย ย โโโ arviz-darkgrid.mplstyle
โย ย โย ย โโโ arviz-whitegrid.mplstyle
โย ย โโโ traceplot.py
โย ย โโโ violinplot.py
โโโ stats
โย ย โโโ diagnostics.py
โย ย โโโ __init__.py
โย ย โโโ stats.py
โโโ tests
โโโ helpers.py
โโโ __init__.py
โโโ saved_models
โย ย โโโ 3.6_pymc3_3.5_500_2.pkl
โย ย โโโ 3.6_pystan_2.18.0.0_500_2.pkl
โโโ test_data.py
โโโ test_diagnostics.py
โโโ test_plots.py
โโโ test_plot_utils.py
โโโ test_stats.py
7 directories, 41 files
Marking this as done, by the way.
Most helpful comment
My only hesitation with that is that there will be different return types (turning a numpy array into inference data is a _ton_ of guessing about intentions). What about exposing
in the top level, and rename the directory to
convert, so you canaz.convert.dict_to_datasetoraz.convert.numpy_to_dataarrayif you need extra specificity.I know it is not consistent, but I sort of like that
from_pymc3accepts atraceargument, whilefrom_stanaccepts afitobject, which will be familiar to users of the library. Hopefullyfrom_pyroandfrom_tfpwill show up soon!