Using the stateful API (functions and attributes of the matplotlib.pyplot module) correctly gets increasingly tricky as a libraries that depends on matplotlib grows larger.
MuMoT's use of matplotlib would be cleaner if something like the following were adoped:
- For non-multi MuMoTview instances a
Figure and Axes pair are instantiated in __init__() using plt.subplots() unless an Axes instance is passed as a param to __init__(), in which case a reference to the associated Figure can be found via the Axes ref. The references to the Figure and Axes are stored as instance attributes (e.g. as self._ax and self._fig).
- Subsequent plotting and changing of aesthetics in other MuMoTview (or non-multi subclass) methods could be done by calling methods of
self._ax or self._fig (rather than the stateful plt.plot/plt.gcf()/plt.gca()/plt.clf()/plt.cla() etc).
My knowledge of how the parts of mumot/view.py fit together is still rather shakey. What issues can others foresee with the above? Would a positive side-effect be that self._figureNum would be redundant? How would the above work with MuMoTmultiViews?
Using the stateful API (functions and attributes of the
matplotlib.pyplotmodule) correctly gets increasingly tricky as a libraries that depends on matplotlib grows larger.MuMoT's use of matplotlib would be cleaner if something like the following were adoped:
FigureandAxespair are instantiated in__init__()usingplt.subplots()unless anAxesinstance is passed as a param to__init__(), in which case a reference to the associatedFigurecan be found via theAxesref. The references to theFigureandAxesare stored as instance attributes (e.g. asself._axandself._fig).self._axorself._fig(rather than the statefulplt.plot/plt.gcf()/plt.gca()/plt.clf()/plt.cla()etc).My knowledge of how the parts of
mumot/view.pyfit together is still rather shakey. What issues can others foresee with the above? Would a positive side-effect be thatself._figureNumwould be redundant? How would the above work withMuMoTmultiViews?