-
Notifications
You must be signed in to change notification settings - Fork 4
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
gempyor
API docstring refurbishment
#468
base: dev
Are you sure you want to change the base?
Conversation
…mprzy/flepiMoP into gempyor-docstring-improvements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good, I think an improvement over the current state. A few themes:
- What's up with putting the file name as the header of a module docstrings? Seems redundant.
- There are some typing signatures that are off, I'd rather have no type signature than an incorrect one so if it's not clear let's leave it for another PR.
- There were some docstrings of CLI commands that were edited in ways that I think will look off when using
--help
, I think we need to be careful about not applying the same docstring style to click commands.
This PR can also be used to address GH #431 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, seems like this wasn't submitted
Attributes: | ||
seir_modifiers_scenario: | ||
outcome_modifiers_scenario: | ||
modinf: A `ModelInfo` object. | ||
already_built: Flag to determine if necessary objects have been built. | ||
autowrite_seir: Flag to automatically write SEIR data after simulation. | ||
static_sim_arguments: Dictionary containing static simulation arguments. | ||
do_inference: Flag to determine if model should be run with inference. | ||
silent: Flag indicating whether to supress output messaging. | ||
save: Flag indicating whether simulation results should be saved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking at the sphinx autdoc syntax, seems like these can defined inline with the various self.attributeA = ...
declarations in init
@TimothyWillard feels to me like we should prefer that approach, what do you think?
I kinda see these primarily as internal structure that we shouldn't advertise via the API anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming you're referring to this syntax: https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#doc-comments-and-docstrings?
I haven't used it before (only used the Attributes
section docstring), but it looks easier so sounds good to me. Can also do this with the sphinx specific PR when we get there.
I kinda see these primarily as internal structure that we shouldn't advertise via the API anyway.
Agree, but these are advertised as public by naming convention and it is beyond the scope of this PR to change that. We should create a follow up to address separately and treat as public for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimothyWillard , so is it your opinion that we leave the attributes in this documentation, or should I remove them since they aren't part of the public-facing API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are a part of the public facing API right now, so I think we should document it and if we want to change that we should do that in a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. In that case I have responded to all requested changes and this can either be re-reviewed or merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine overall - probably fix the one case of repeating the information from the type hint in the documentation, which sphinx should make unnecessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor things, all but one are suggestions that can be taken or left. Only thing I couldn't suggest in the PR review GUI was the import order thing (I think because it involves LOC that weren't edited). Otherwise LGTM let's push forward for sphinx!
""" | ||
This method is called by the constructor if the compartments are not loaded from a file. | ||
It will parse the compartments and transitions from the configuration files. | ||
It will populate self.compartments and self.transitions. | ||
It will populate dynamic class attributes `self.compartments` and `self.transitions`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will populate dynamic class attributes `self.compartments` and `self.transitions`. | |
It will populate dynamic class attributes `compartments` and `transitions`. |
Facilitates the calibration of the model using the `emcee` MCMC sampler. | ||
Provides CLI options for users to specify simulation paramters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Facilitates the calibration of the model using the `emcee` MCMC sampler. | |
Provides CLI options for users to specify simulation paramters. | |
Facilitates the calibration of the model using the `emcee` MCMC sampler. | |
Provides CLI options for users to specify simulation parameters. |
Split into header and description (assuming that's the intent?) and typo.
def parse_parameters( | ||
self, parameters: np.ndarray, parameter_names: list, unique_strings: list | ||
) -> np.ndarray: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, realizing I did not reply, not complete is better, we can go back and complete the picture later.
def get_compartments_explicitDF(self): | ||
def get_compartments_explicitDF(self) -> pd.DataFrame: | ||
""" | ||
Returns a copy of the compartments information DataFrame; all columns receive a 'mc_' prefix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returns a copy of the compartments information DataFrame; all columns receive a 'mc_' prefix. | |
Returns a copy of the compartments information DataFrame. | |
All columns receive a 'mc_' prefix. |
@@ -24,6 +45,7 @@ | |||
from . import seir, model_info | |||
from . import outcomes, file_paths | |||
from .utils import config, Timer, read_df, as_list | |||
from typing import Literal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you if you want to do this now or later, but let's try to follow PEP8 for imports going forward (i.e. move this up to stdlib imports rather than with local pkg imports): https://peps.python.org/pep-0008/#imports
""" | ||
Defines the `ModelInfo` class (and associated methods), used for setting up and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
""" | |
Defines the `ModelInfo` class (and associated methods), used for setting up and | |
""" | |
Abstractions for interacting with models as a monolithic object. | |
Defines the `ModelInfo` class (and associated methods), used for setting up and |
Add header line.
Co-authored-by: Carl A. B. Pearson <[email protected]>
Describe your changes.
This pull request:
gempyor
gempyor
, it does not propagate poor documentationAs I see it, the
gempyor
API mainly consists of:ModelInfo
class frommodel_info.py
Parameters
class fromparameters.py
, and some associated methodsGempyorInference
class frominference.py
, and some associated methodsCompartments
class fromcompartments.py
, and some associated methodsutils.py
(read_df
andwrite_df
)Note, before narrowing my focus on guidance from Carl, I also wrote some docstring in two files (
calibrate.py
andcli.py
). I do not think of these as being integral parts of thegempyor
API, but because I worked on them in in the same sweep of work that I worked on the others, they are also included in this PR with some docstring improvements.What does your pull request address? Tag relevant issues.
This pull request addresses GH #462.