MEP25: Serialisierung #

Status #

Abgelehnt

Diese Arbeit ist wichtig, aber diese besondere Anstrengung ist ins Stocken geraten.

Branches und Pull-Requests #

  • Entwicklungszweige:

  • verwandte Pull-Requests:

Zusammenfassung #

Dieses MEP zielt darauf ab, serialisierbare ControllerObjekte hinzuzufügen, die als ArtistManager fungieren. Benutzer würden dann Änderungen an Artistüber eine Controller. Auf diese Weise kann die Funktionalität der ControllerObjekte schrittweise hinzugefügt werden, da jedes Artistimmer noch dafür verantwortlich ist, alles zu zeichnen. Das Ziel besteht darin, eine API zu erstellen, die sowohl von Grafikbibliotheken, die Beschreibungen von Abbildungen auf hoher Ebene erfordern, als auch von Bibliotheken, die Interpretationen auf niedriger Ebene erfordern, verwendbar ist.

Detaillierte Beschreibung #

Matplotlib ist eine Kernplot-Engine mit einer API, die viele Benutzer bereits verstehen. Für andere Grafikbibliotheken ist es schwierig/unmöglich, (1) eine vollständige Abbildungsbeschreibung zu erhalten, (2) Rohdaten aus dem Abbildungsobjekt so auszugeben, wie der Benutzer sie bereitgestellt hat, (3) die Semantik der Abbildungsobjekte ohne Heuristik zu verstehen und ( 4) Matplotlib eine vollständige Figurenbeschreibung zur Visualisierung geben. Da an außerdem Artistkeine Vorstellung von seiner eigenen Semantik innerhalb der Figur hat, ist es schwierig, auf natürliche Weise mit ihnen zu interagieren.

In diesem Sinne wird Matplotlib ein Standard-Model-View-Controller (MVC)-Framework übernehmen. Das Modell besteht aus den benutzerdefinierten Daten, dem Stil und der Semantik. Die Views sind die Gesamtheit jedes Einzelnen Artist, die für die Erstellung des endgültigen Bildes auf der Grundlage des Modells verantwortlich sind . Der Controller ist das ControllerObjekt, das seinen Satz von ArtistObjekten verwaltet.

Der Controllermuss in der Lage sein, die Informationen, die er über die Figur trägt, auf Befehl zu exportieren, vielleicht über eine to_jsonMethode oder ähnliches. Da es äußerst irrelevant wäre, alle Informationen im Modell mit dem Controller zu duplizieren, werden nur benutzerspezifische Informationen (Daten + Stil) explizit beibehalten. Wenn ein Benutzer weitere Informationen (Standardwerte) von der Ansicht/dem Modell wünscht, sollte er in der Lage sein, danach zu fragen.

  • Dies kann lästig sein, da nicht spezifizierte kwargs aus dem rcParams-Objekt gezogen werden, das wiederum aus dem Lesen einer benutzerdefinierten Datei erstellt wird und zur Laufzeit dynamisch geändert werden kann. Ich nehme an, wir könnten ein Diktat der Standardwerte führen und damit vergleichen. Es ist nicht klar, wie dies mit dem Stylesheet [[MEP26]] - @tacaswell interagieren wird

Zusätzliche Bemerkungen:

  • Die "Rohdaten" müssen nicht unbedingt ein list, ndarray, usw. sein. Vielmehr können sie abstrakter nur eine Methode haben, um bei Bedarf Daten zu liefern.

  • Da die Controllerzusätzliche Informationen enthält, die Benutzer möglicherweise nicht aufbewahren möchten, sollte sie nicht standardmäßig erstellt werden. Sie sollten in der Lage sein, sowohl (a) a Controller mit einer Figur zu instanziieren als auch (b) eine Figur mit a zu erstellen Controller.

Anwendungsfälle:

  • Exportieren Sie alle erforderlichen Informationen

  • Eine Matplotlib-Figur serialisieren, speichern und später erneut ausführen können.

  • Jede andere Quelle, die eine entsprechend formatierte Darstellung zum Öffnen an matplotlib sendet

Beispiele #

Hier sind einige Beispiele dafür, was die Controller können sollten.

  1. Instanziieren Sie eine Matplotlib-Figur aus einer serialisierten Darstellung (z. B. 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. Künstler vom Controller aus verwalten (z. B. Line2D):

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

  3. Serialisierbare Figurendarstellung exportieren:

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

Implementierung #

  1. Erstellen Sie Basisobjekte Controller, die Objekte verwalten Artistkönnen (z. B. Hist)

    Kommentare:

    • Die Initialisierung sollte über das Entpacken erfolgen **, daher benötigen wir eine Kopie des Anrufsignaturparameters für den, den Artistwir letztendlich zu kontrollieren versuchen. Unglückliche fest codierte Wiederholung ...

    • sollte die **kwargsjeweils zusätzlich akzeptierte Artist nachverfolgt werdenController

    • woher weiß man Controller, welcher künstler wohin gehört? Müssen wir zB axesReferenzen übergeben?

    Fortschritt:

  2. Protokolle schreiben , um das Modell Controllerzu aktualisieren .

    Kommentare:

    • Wie ist mit Containern umzugehen? Was passiert zB mit alten Patches, wenn wir ein Histogramm neu ordnen?

    • Im Link von (1) wird die alte Linie vollständig zerstört und neu gezeichnet. Was ist, wenn etwas darauf verweist?

  3. Create-Methode, mit der ein JSON-Objekt aus der zusammengestellt werden kann Controllers

  4. Umgang mit der Serialisierung der deserialisierbaren Aspekte einer Figur (z. B. nicht-affine Transformationen?)

  5. In der Lage sein, aus einer serialisierten Darstellung zu instanziieren

  6. Reimplementieren Sie die vorhandene Pyplot- und Axes-Methode, z. B. pyplot.histund Axes.histin Bezug auf die neue Controller-Klasse.

> @theengineer: in Nr. 2 oben, was meinst du damit , Updates von jedem zu erhalten Artist?

^ Ja. Die Controller sollten nicht aktualisiert werden müssen. Das passiert einfach in #3. Löschen Sie Kommentare, wenn Sie dies sehen.

Abwärtskompatibilität #

  • Beizen wird sich ändern

  • nicht-affine Transformationen erfordern ein definiertes Beizverfahren

Alternativen #

PR #3150 schlug vor, Semantik hinzuzufügen, indem zusätzliche Container parasitär an Achsenobjekte angehängt wurden. Dies ist eine vollständigere Lösung mit einem entwickelteren/flexibleren/leistungsstärkeren Framework.