PyBaMM icon indicating copy to clipboard operation
PyBaMM copied to clipboard

Make private functions and classes more explicit

Open valentinsulzer opened this issue 3 years ago • 5 comments

Make it clearer which methods should not be accessed by users, by adding an underscore at the start of their name

valentinsulzer avatar Nov 03 '22 19:11 valentinsulzer

We should also look into adding __all__ to pybamm modules

Copied from the PR linked above

Saransh-cpp avatar Mar 05 '24 15:03 Saransh-cpp

There was an attempt by @arjxn-py on adding __all__ with the mkinit CLI-based package to speed up the PyBaMM import, but there were problems with that approach (#3732) because it would be messy to add it to several files at once and generate it everytime. Here is an older thread I found, probably not relevant anymore: #2436

It would make sense to start with smaller modules like util.py, doc_utils.py, install_odes.py (the latter should just have one method of usage – through the entry point). Also, version.py should be a private module too (pybamm._version.__version__ instead of pybamm.version.__version__), and it could be altered in favour of using importlib.metadata.version() to fetch the version from declarative metadata – in 2024 we should not need to import a package to obtain its version

agriyakhetarpal avatar Mar 05 '24 15:03 agriyakhetarpal

It should be possible to add __all__ only as well with the help of mkinit, how'd we want to have it though -

  • have __all__ added to all the submodules? (Not Recommended - as it would again be messy with several file changes)
  • have a recursive __all__ added to the root __init__.py (Recommended - See this commit)
  • have a non-recursive __all__ added to the root __init__.py (See this commit, Makes lesser sense as it only includes direct attributes of pybamm)

arjxn-py avatar Mar 07 '24 11:03 arjxn-py

The second one makes the most sense to me, it should decide the namespace when we import PyBaMM.

The third one would need a bit more refining because we have things like update_LD_LIBRARY_PATH which should not be exposed

agriyakhetarpal avatar Mar 07 '24 15:03 agriyakhetarpal

The third one would need a bit more refining because we have things like update_LD_LIBRARY_PATH which should not be exposed

We also have these attributes in the second too, as ultimately:

  • First is the superset of Second & Third &
  • Second is the superset of Third

Currently Protected modules are exposed, but their attributes are not & Private modules and their attributes are not exposed.

I shall open a PR going forward with the second at the moment but to refine this i'd welcome reviews to omit attributes based upon different preferences.

arjxn-py avatar Mar 08 '24 05:03 arjxn-py