Switch to using matplotlib's object-oriented API
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Refactoring
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- data-visualization
Direzione di ricerca
Inizia in mumot/view.py e segui MuMoTview e MuMoTmultiView, in particolare init e gli utilizzi dello stato di pyplot come plt.gcf(), plt.gca(), plt.clf() e plt.cla(). Confronta la proprietà proposta di Figure/Axes con il comportamento esistente di _figureNum e determina come funzionerebbe un argomento Axes opzionale per entrambi i tipi di vista; l'issue è conclusa quando il design e i siti di chiamata interessati sono concordati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
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). - Subsequent plotting and changing of aesthetics in other MuMoTview (or non-multi subclass) methods could be done by calling methods of
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.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?
- Lingua principale
- Python
- Stelle
- 24
- Fork
- 5
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DiODeProject/MuMoT
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
DiODeProject/MuMoT#418 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
DiODeProject/MuMoT#412 · 1 commento ·
-
Changing visualisation type of MuMoTstochasticSimulationViews through GUI causes plot deformations (squeezing)Forse di nuovo libera @joefresna l’ha presa 2298 giorni fa e non c’è nessuna pull request aperta. Apertabug
DiODeProject/MuMoT#409 · 1 assegnatario ·
-
bug testing
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
DiODeProject/MuMoT#407 · 2 commenti ·
-
Use of bare 'except:' is badApertabug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
DiODeProject/MuMoT#387 · 1 commento ·
Tutte le issue di DiODeProject/MuMoT
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Deltares/imod-python#1940 ·
I maintainer di solito rispondono entro 1 giorno
-
effort: low prio: low ready
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
digitalfabrik/integreat-cms#4621 ·
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
ioos/compliance-checker#1375 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno