Revisit workflow for importing submodules

[Eirik Keilegavlen]

The file structure in PorePy make extensive use of folders and subfolders, organized in a semi-logical way. To facilitate easy access to classes and modules, __ init __-files are used to enable, for instance pp.Mpfa as an alias for pp.numerics.fv.mpfa.Mpfa. While this by itself is a sound approach that we in the main would like to keep, it also has several shortcomings:

• The current use of __ init __ is top-down, in the sense that the top-level __ init __ fetches individual functions and classes. An alternative approach, which may be more pythonic, is to iteratively use sub-package __ inits __ together with the keyword __ all __, to build the structure bottom-up. An experiment in this direction can be found in pp.numerics.ad and its associated modules. It is unclear what is the best way of doing this, and whether it makes sense to strive for 'best' or just 'this works', but a principled approach based on some research into pros and cons is lacking.
• There is no policy on what are private and public classes and modules, in the pythonic sense. Nor do we have a way to mark this in the code, e.g. by letting private modules have names starting with an underscore and/or be included in an __ all __ statement/import in __ init __. While there may be several acceptable approaches here, it is tempting to wish for a scheme which forces the developer to explicitly consider if a new function, class, or method is public or not, and similarly informs the user.
• If we get a solution for the above points, it is natural to let all public classes be acceptable through pp.ClassName, all public modules as pp.module_name. What to do with individual functions is not crystal clear, but may become so with considering a few cases.

There may be more to this, we should amend the issue as things become clearer.

[Jhabriel Varela]

When I investigated this in the past, I remember finding this answer quite informative: https://stackoverflow.com/a/35710527