You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Time to split up base_plotting.py into individual module files #685
There will be even more modules coming too! I think we should make things modular and split each pygmt.Figure function into it's own standalone file like so:
Note that we originally had a gmt/modules folder but that was removed in 252d5df, and the big Figure class was made because of a decision to use an object orientated style (i.e. fig.plot(), fig.grdimage(), etc) at some point in 2017. I believe there should be a way to keep that object orientated style while splitting the class into several files, so this refactor should provide the same functionality for our users going forward.
Transition state
To ease the transition, we can do it chunk by chunk:
Split off the big supplementary modules (i.e. meca)
Split off the grid plotting functions (grdcontour, grdimage, grdview)
@weiji14 Please pardon my ignorance on how this should be done, but are you envisioning that figure.py will directly import all of the different plotting methods separately (that have all be moved from base_plotting.py to their separate scripts) to be used by Figure and bypass BasePlotting? As far as I can tell, the tests should be unaffected, as long as pygmt.Figure() is able to use plotting methods.
I'd be happy to help on this issue, but am unfamiliar with the process of moving class methods to separate scripts. Are there any previous commits that demonstrate how this should be done? Thanks!
@weiji14 Please pardon my ignorance on how this should be done, but are you envisioning that figure.py will directly import all of the different plotting methods separately (that have all be moved from base_plotting.py to their separate scripts) to be used by Figure and bypass BasePlotting? As far as I can tell, the tests should be unaffected, as long as pygmt.Figure() is able to use plotting methods.
Essentially yes. The intention is to have each function be a standalone thing in one file. We may or may not keep a BasePlotting class intact, the implementation details are quite flexible at the moment.
I'd be happy to help on this issue, but am unfamiliar with the process of moving class methods to separate scripts. Are there any previous commits that demonstrate how this should be done? Thanks!
There's actually a work in progress PR at #686 which started to tackle this, but I got stuck (hitting the limits of my object-orientated Python knowledge) as every stackoverflow question on splitting up a Python class into separate files appears too hacky. You could start having a look there, or feel free to come up with an alternative!
I'll take a look (AKA Google search) for some options. My initial thought when it seemed like too much work to have a Python class in separate files was to have each module be its separate class, but that just seems like it would make Figure too big and cumbersome instead of BasePlotting.
Until this gets changed, can the 2000 line length be dropped from the style checks?
You can disable this check on just the one file (base_plotting.py) using # pylint: disable=something where 'something' is the pylint error. I'll try and follow up on #686 PR sometime next month, or feel free (anyone) to have a go at this issue.
Until this gets changed, can the 2000 line length be dropped from the style checks?
You can disable this check on just the one file (base_plotting.py) using # pylint: disable=something where 'something' is the pylint error. I'll try and follow up on #686 PR sometime next month, or feel free (anyone) to have a go at this issue.
Good to know, recently ran into the same issue during the creation of the rose wrapper.
@weiji14 I definitely haven't made any progress on this. What are your thoughts on at least moving the parameters to a separate file, not unlike how we keep common parameters in COMMON_OPTIONS. My thought is that we could organize it somewhat like the test files (e.g. have a parameters_coast.py and parameters_basemap.py). It leaves us with the issue that base_plotting.py has so many functions in the Figure class, but it at least moves hundreds of lines of code out of the class without functional changes to the module.
Alright people, #686 is merged so most new plotting modules (i.e. those called using fig.something) should go into the pygmt/src folder whenever possible to keep base_plotting.py short (<3000 lines) This applies to open PRs for rose (#794) and solar (#804), we can open a separate issue to discuss if data processing modules like grd2cpt (#803) needs to go under pygmt/src.
See meca.py example for how it's done. You'll also need to add some lines at two other places like so:
@GenericMappingTools/python-maintainers I think we should move our existing plotting functions to their own modules, not just the new ones, for the sake of consistency. If this is what we want, I'm happy to work on it; I'm still quarantined for another few days.
Looking at the changes in #808. It seems boring to modify two files. Perhaps we should revert to @weiji14's initial design (i.e., keep pygmt/src/__init__.py empty and use from pygmt.src.meca import meca in pygmt/base_plotting.py)?
I think think it would be best to have a single import statement, like from pygmt.src import grdimage, plot, solar and the like. It would make the final import statements look cleaner, but the downside is that there is an extra __init__.py.
I think think it would be best to have a single import statement, like from pygmt.src import grdimage, plot, solar and the like. It would make the final import statements look cleaner, but the downside is that there is an extra __init__.py.
Closed by #808, thanks @willschlitzer! Note that base_plotting.py was deleted, and all modules (e.g. grdimage, colorbar, etc) are imported directly in figure.py now.
Activity
weiji14 commentedon Nov 7, 2020
Can someone remind me what the
_preprocessfunction inbase_plotting.pydoes? I never quite understood what it's meant to do 😕pygmt/pygmt/base_plotting.py
Lines 29 to 55 in d3e131a
seisman commentedon Nov 8, 2020
I think it does nothing here, but the
_preprocessfunction in theFigureclass does something.willschlitzer commentedon Dec 2, 2020
@weiji14 Please pardon my ignorance on how this should be done, but are you envisioning that
figure.pywill directly import all of the different plotting methods separately (that have all be moved frombase_plotting.pyto their separate scripts) to be used byFigureand bypassBasePlotting? As far as I can tell, the tests should be unaffected, as long aspygmt.Figure()is able to use plotting methods.I'd be happy to help on this issue, but am unfamiliar with the process of moving class methods to separate scripts. Are there any previous commits that demonstrate how this should be done? Thanks!
weiji14 commentedon Dec 2, 2020
Essentially yes. The intention is to have each function be a standalone thing in one file. We may or may not keep a
BasePlottingclass intact, the implementation details are quite flexible at the moment.There's actually a work in progress PR at #686 which started to tackle this, but I got stuck (hitting the limits of my object-orientated Python knowledge) as every stackoverflow question on splitting up a Python class into separate files appears too hacky. You could start having a look there, or feel free to come up with an alternative!
willschlitzer commentedon Dec 2, 2020
I'll take a look (AKA Google search) for some options. My initial thought when it seemed like too much work to have a Python class in separate files was to have each module be its separate class, but that just seems like it would make
Figuretoo big and cumbersome instead ofBasePlotting.willschlitzer commentedon Jan 21, 2021
Until this gets changed, can the 2000 line length be dropped from the style checks?
weiji14 commentedon Jan 21, 2021
You can disable this check on just the one file (base_plotting.py) using
# pylint: disable=somethingwhere 'something' is the pylint error. I'll try and follow up on #686 PR sometime next month, or feel free (anyone) to have a go at this issue.michaelgrund commentedon Jan 22, 2021
Good to know, recently ran into the same issue during the creation of the rose wrapper.
willschlitzer commentedon Jan 24, 2021
@weiji14 I definitely haven't made any progress on this. What are your thoughts on at least moving the parameters to a separate file, not unlike how we keep common parameters in COMMON_OPTIONS. My thought is that we could organize it somewhat like the test files (e.g. have a
parameters_coast.pyandparameters_basemap.py). It leaves us with the issue thatbase_plotting.pyhas so many functions in theFigureclass, but it at least moves hundreds of lines of code out of the class without functional changes to the module.lint: Increase max-module-lines to 3000 (#805)
weiji14 commentedon Jan 26, 2021
Alright people, #686 is merged so most new plotting modules (i.e. those called using
fig.something) should go into thepygmt/srcfolder whenever possible to keepbase_plotting.pyshort (<3000 lines) This applies to open PRs forrose(#794) andsolar(#804), we can open a separate issue to discuss if data processing modules likegrd2cpt(#803) needs to go underpygmt/src.See
meca.pyexample for how it's done. You'll also need to add some lines at two other places like so:pygmt/pygmt/src/__init__.py
Line 5 in 2345486
pygmt/pygmt/base_plotting.py
Lines 1645 to 1646 in 2345486
Sorry if this gives people more work, but it will make
pygmta bit more manageable into the future as we wrap > 100 gmt modules available at https://docs.generic-mapping-tools.org/latest/modules.html.willschlitzer commentedon Jan 27, 2021
@GenericMappingTools/python-maintainers I think we should move our existing plotting functions to their own modules, not just the new ones, for the sake of consistency. If this is what we want, I'm happy to work on it; I'm still quarantined for another few days.
seisman commentedon Jan 28, 2021
Looking at the changes in #808. It seems boring to modify two files. Perhaps we should revert to @weiji14's initial design (i.e., keep
pygmt/src/__init__.pyempty and usefrom pygmt.src.meca import mecainpygmt/base_plotting.py)?willschlitzer commentedon Jan 28, 2021
I think think it would be best to have a single import statement, like
from pygmt.src import grdimage, plot, solarand the like. It would make the final import statements look cleaner, but the downside is that there is an extra__init__.py.seisman commentedon Jan 29, 2021
It's OK to me.
weiji14 commentedon Feb 7, 2021
Closed by #808, thanks @willschlitzer! Note that
base_plotting.pywas deleted, and all modules (e.g.grdimage,colorbar, etc) are imported directly infigure.pynow.lint: Increase max-module-lines to 3000 (GenericMappingTools#805)