Repository navigation
Rename module files in plotting folder - #554
Conversation
jl-wynen
left a comment
There was a problem hiding this comment.
Do the renamed files contain any public code that users should access via the full path (pp.slicer_plot.foo) or only code that is re-exported through __init__.py (pp.foo)? In the latter case, can we make the modules protected (_slicer.py) to simplify the UI, e.g., in autocompletions?
|
I think users should not have to import anything from the files in those modules, only from the So are you suggesting instead of the renames that I did, to rename |
Yes |
|
I tried running the tests in |
The
plottingfolder contains the most commonly used functions/modules.Most files in that module contained a function with the same name as a file itself.
Because of the lazy-loader and how import mechanics work, we ran into the following problem:
So after importing the
Slicerclass, we can no longer call thepp.slicerfunction.Here's what happens:
plopp.__init__.pyuses lazy.attach to lazily expose slicer (the function) from the plotting submodule atpp.slicer.When we
from plopp.plotting.slicer import Slicer, Python imports the moduleplopp.plotting.slicerand, as part of the import machinery, sets it as an attribute on theplopp.plottingpackage:plopp.plotting.slicer = <module>.Now when the notebook later accesses
pp.slicer, the lazy loader resolves it by doing fromplopp.plotting import slicer. Butplopp.plotting.sliceris now the module (set in step 2), not the function. Sopp.slicerbecomes the module, and calling it fails withTypeError: 'module' object is not callable.So in this PR, we rename the files in these modules to avoid the name clashes.
There are probably other files in the Plopp codebase where this also happens, but for now we only rename the most used/important modules.
We can always fix more later.
I am hoping that very little code will be broken by this change, as most code or notebooks should be importing from
ploppand not fromplopp.plotting.slicer.