search

FiniteVolumeTransportPhenomena / PyFVTool

Finite volume toolbox in Python
GNU Lesser General Public License v2.1
13 stars 4 forks source link

Standardize pyfvtool imports on the user side #27

Closed mhvwerts closed 7 months ago

mhvwerts commented 8 months ago

In anticipation of future work on #15, it may be wise to define more explicitly the boundary between the 'user' ('public') side and the internal ('private') PyFVTool code. Standardizing the way PyFVTool is imported in user code will contribute to this.

For instance, the user code would only use a single import statement:

import pyfvtool as pf

and then call the public PyFVTool functions, e.g. pf.createMesh1D(), pf.createCellVariable().

All 'user' functions should thus be made available via the pyfvtool/__init__.py script. This is likely already the case.

Deeper imports and digging up 'private' PyFVTool functions should be strongly discouraged. The casual user (like myself) should (eventually) not need to consult the core PyFVTool code.

We may already start by adapting existing tests, examples and Notebooks to adhere to this import standard, a process which will reveal any user functionality still missing from pyfvtool/__init__.py (if any).

mhvwerts commented 8 months ago

P.S. Star imports are generally discouraged in Python. Avoid from pyfvtool import *

mhvwerts commented 7 months ago

The removal of the star imports in the pyfvtool module base code facilitates linting and debugging with the IDE that I use (Spyder which has pyflakes as the automatic linter).

BTW, pyflakes detects unused local variables in two of the routines in advection.py (convectionUpwindTermCylindrical3D, and convectionTvdRHSCylindrical3D), variables that are used in the calculation of the matrix elements, but never make it into the final result. I did not look in detail, there may good reasons to have them (completeness of the mathematical development), but may be worth a look some time.