The class CRO_SL is the only class/method with a respectable docstring. Having proper docstrings can help to auto-generate with Sphinx the Documentation of the pkgs in order to make it available. And this will help other people to contribute to pkgs if some bus/issue found, or if they propose some kind of enhancement.
I propose to add the corresponding docstrings following the PEP 257 convention. Specifically, I propose the following structure:
"""
name_of_class_or_method
Description of class or method functionality, and main notes or caveats about it.
Parameters
----------
name_param1: type(s)
Description of parameter details.
name_param2: type(s)
Description of parameter details.
Returns
---------
name_of_return[optional]: type(s)
Description of return details.
"""
In order to make more easy the documentation and the tracking of this issue, I provide a list of .py files where the docstrings needs to be added as a task list. When a commit in a specific branch for documentation finish the docstrings of a file, it can be marked as completed:
Also, if any of you disagree with the propose issue, or with the task list, comments and suggestions are welcome.
The class
CRO_SLis the only class/method with a respectable docstring. Having proper docstrings can help to auto-generate withSphinxthe Documentation of the pkgs in order to make it available. And this will help other people to contribute to pkgs if some bus/issue found, or if they propose some kind of enhancement.I propose to add the corresponding docstrings following the PEP 257 convention. Specifically, I propose the following structure:
In order to make more easy the documentation and the tracking of this issue, I provide a list of .py files where the docstrings needs to be added as a task list. When a commit in a specific branch for
documentationfinish the docstrings of a file, it can be marked as completed:Also, if any of you disagree with the propose issue, or with the task list, comments and suggestions are welcome.