Closed mhvwerts closed 7 months ago
P.S. Star imports are generally discouraged in Python. Avoid from pyfvtool import *
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.
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:
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).