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
Current structure of code leads to circular dependencies or classes as modules #352
Comments
I can live with either choice, but my personal preference would be to probably empty out the init files and force the use of the full names e.g. Primarily because keeping the class loads in the init files means, for consistency, we will have to add every future py file as an import in the appropriate init (or end up with some classes loaded, some not, with different pathing required). It's one more thing to remember to do. |
To make it simple, I prefer to use the full names (both actually are fine). Currently I removed Platform import from init.py and use the following instead wherever needed:
|
I still think we should snake_case the filenames as well so we can have a unique reference name for both the class and file.. ie platform_simulation and PythonSimulation |
From https://www.python.org/dev/peps/pep-0008/#package-and-module-names
|
Just chiming in to note that the current naming structure causes the class name to be repeated in the signature for API docs built with Sphinx too. You can see this in the DTK-Tools docs here: https://institutefordiseasemodeling.github.io/Documentation/dtk-tools/dtk/dtk.utils.Campaign.utils.html#module-dtk.utils.Campaign.utils.CampaignManager |
…andards and prevent issues
Because of the way we important files into init.py and the fact are class files are the same name of the class, we end up with either a circular import or modules confused as classes. We should either
@ckirkman-IDM @ZDu-IDM @braybaud , what is your preferred option?
The text was updated successfully, but these errors were encountered: