MEP25: Serializzazione #

Stato n.

Respinto

Questo lavoro è importante, ma questo particolare sforzo si è bloccato.

Filiali e Pull request #

  • rami di sviluppo:

  • richieste pull correlate:

Estratto n.

Questo MEP mira ad aggiungere Controlleroggetti serializzabili per agire come Artistgestori. Gli utenti comunicherebbero quindi le modifiche a un Artisttramite a Controller. In questo modo, la funzionalità degli Controlleroggetti può essere aggiunta in modo incrementale poiché ognuno Artistè ancora responsabile del disegno di tutto. L'obiettivo è creare un'API che sia utilizzabile sia mediante rappresentazione grafica di librerie che richiedono descrizioni di figure di alto livello, sia di librerie che richiedono interpretazioni di basso livello.

Descrizione dettagliata #

Matplotlib è un motore di plottaggio di base con un'API che molti utenti già comprendono. È difficile/impossibile per altre librerie grafiche (1) ottenere una descrizione completa della figura, (2) emettere dati grezzi dall'oggetto figura così come li ha forniti l'utente, (3) comprendere la semantica degli oggetti figura senza euristica e ( 4) fornire a matplotlib una descrizione completa della figura da visualizzare. Inoltre, poiché an Artistnon ha idea della propria semantica all'interno della figura, è difficile interagire con esse in modo naturale.

In questo senso, matplotlib adotterà un framework MVC (Model-View-Controller) standard. Il modello sarà costituito dai dati, dallo stile e dalla semantica definiti dall'utente. Le Views sono l'insieme di ogni individuo Artist, che ha il compito di produrre l'immagine finale basata sul modello . Il Controller sarà l' Controlleroggetto che gestisce il suo insieme di Artistoggetti.

Deve essere in grado di esportare a comando le Controllerinformazioni che sta portando sulla figura, magari tramite un to_jsonmetodo o simili. Poiché sarebbe estremamente estraneo duplicare tutte le informazioni nel modello con il controller, vengono mantenute esplicitamente solo le informazioni specificate dall'utente (dati + stile). Se un utente desidera maggiori informazioni (predefinite) dalla vista/modello, dovrebbe essere in grado di interrogarle.

  • Questo potrebbe essere fastidioso da fare, i kwargs non specificati vengono estratti dall'oggetto rcParams che a sua volta viene creato dalla lettura di un file specificato dall'utente e può essere modificato dinamicamente in fase di esecuzione. Suppongo che potremmo tenere un dict di default default e confrontarlo con quello. Non è chiaro come questo interagirà con il foglio di stile [[MEP26]] - @tacaswell

Note aggiuntive:

  • I "dati grezzi" non devono necessariamente essere un list, ndarray, ecc. Piuttosto, in modo più astratto possono avere solo un metodo per fornire dati quando necessario.

  • Poiché Controllerconterrà informazioni aggiuntive che gli utenti potrebbero non voler conservare, non dovrebbe essere creato per impostazione predefinita. Dovresti essere in grado di (a) istanziare a Controller con una figura e (b) costruire una figura con a Controller.

Casi d'uso:

  • Esporta tutte le informazioni necessarie

  • Serializzare una figura matplotlib, salvarla e poterla rieseguire in seguito.

  • Qualsiasi altra fonte che invia una rappresentazione opportunamente formattata a matplotlib per l'apertura

Esempi #

Ecco alcuni esempi di ciò che i controllori dovrebbero essere in grado di fare.

  1. Crea un'istanza di una figura matplotlib da una rappresentazione serializzata (ad esempio, JSON):

    import json
from matplotlib.controllers import Controller
with open('my_figure') as f:
    o = json.load(f)
c = Controller(o)
fig = c.figure

  2. Gestisci gli artisti dal controller (ad esempio, Line2D):

    # not really sure how this should look
c.axes[0].lines[0].color = 'b'
# ?

  3. Esporta rappresentazione della figura serializzabile:

    o = c.to_json()
# or... we should be able to throw a figure object in there too
o = Controller.to_json(mpl_fig)

Implementazione n.

  1. Creare Controlleroggetti di base in grado di gestire Artistoggetti (ad esempio, Hist)

    Commenti:

    • l' inizializzazione dovrebbe avvenire tramite unpacking **, quindi abbiamo bisogno di una copia del parametro di firma della chiamata per il Artistche alla fine stiamo cercando di controllare. Sfortunata ripetizione codificata...

    • dovrebbe essere rintracciato l'ulteriore **kwargsaccettato da ciascuno alArtistController

    • come fa a Controllersapere quale artista appartiene a dove? Ad esempio, dobbiamo passare i axesriferimenti?

    Progresso:

  2. Scrivere nei protocolli per Controlleraggiornare il modello.

    Commenti:

    • come devono essere trattati i contenitori? Ad esempio, cosa succede alle vecchie patch quando ribiniamo un istogramma?

    • nel collegamento da (1), la vecchia riga è completamente distrutta e ridisegnata, e se qualcosa vi fa riferimento?

  3. Crea il metodo con cui un oggetto json può essere assemblato dal file Controllers

  4. Gestire la serializzazione degli aspetti non serializzabili di una figura (ad es. trasformazioni non affini?)

  5. Essere in grado di istanziare da una rappresentazione serializzata

  6. Reimplementare il metodo pyplot e Axes esistente, ad esempio pyplot.histe Axes.histin termini della nuova classe controller.

> @theengineer: al n. 2 sopra, cosa intendi per ottenere aggiornamenti da ciascuno Artist?

^ Già. Non Controller dovrebbe essere necessario aggiornarsi. Questo accade solo nel numero 3. Elimina i commenti quando vedi questo.

Compatibilità con le versioni precedenti #

  • il decapaggio cambierà

  • le trasformazioni non affini richiederanno un metodo di decapaggio definito

Alternative #

PR # 3150 ha suggerito di aggiungere la semantica collegando in modo parassitario contenitori aggiuntivi agli oggetti assi. Questa è una soluzione più completa con quello che dovrebbe essere un framework più sviluppato/flessibile/potente.