MEP25: serialización #

Estado #

Rechazado

Este trabajo es importante, pero este esfuerzo en particular se ha estancado.

Sucursales y solicitudes de extracción #

  • ramas de desarrollo:

  • solicitudes de extracción relacionadas:

Resumen #

Este MEP tiene como objetivo agregar Controllerobjetos serializables para actuar como Artistadministradores. Luego, los usuarios comunicarían los cambios a Artisttravés de un archivo Controller. De esta manera, la funcionalidad de los Controllerobjetos se puede agregar de forma incremental, ya que cada uno Artistsigue siendo responsable de dibujarlo todo. El objetivo es crear una API que se pueda utilizar tanto para bibliotecas gráficas que requieran descripciones de figuras de alto nivel como para bibliotecas que requieran interpretaciones de bajo nivel.

Descripción detallada #

Matplotlib es un motor de trazado central con una API que muchos usuarios ya entienden. Es difícil/imposible para otras bibliotecas gráficas (1) obtener una descripción completa de la figura, (2) generar datos sin procesar del objeto de la figura tal como los proporcionó el usuario, (3) comprender la semántica de los objetos de la figura sin heurística y ( 4) dar a matplotlib una descripción completa de la figura para visualizar. Además, debido a Artistque no tiene una concepción de su propia semántica dentro de la figura, es difícil interactuar con ellos de forma natural.

En este sentido, matplotlib adoptará un marco estándar de Modelo-Vista-Controlador (MVC). El Modelo serán los datos, el estilo y la semántica definidos por el usuario. Las Vistas son el conjunto de cada individuo Artist, las cuales se encargan de producir la imagen final a partir del modelo . El Controlador será el Controllerobjeto que gestione su conjunto de Artistobjetos.

ControllerDebe poder exportar la información que lleva sobre la figura a pedido, quizás a través de un método to_jsono similar. Debido a que sería extremadamente extraño duplicar toda la información en el modelo con el controlador, solo se mantiene explícitamente la información especificada por el usuario (datos + estilo). Si un usuario desea obtener más información (valores predeterminados) de la vista/modelo, debería poder consultarla.

  • Esto puede ser molesto de hacer, los kwargs no especificados se extraen del objeto rcParams que, a su vez, se crea al leer un archivo especificado por el usuario y se puede cambiar dinámicamente en tiempo de ejecución. Supongo que podríamos mantener un dictamen de los valores predeterminados predeterminados y compararlos. No está claro cómo interactuará esto con la hoja de estilo [[MEP26]] - @tacaswell

Notas adicionales:

  • Los "datos sin procesar" no necesariamente tienen que ser list, ndarray, etc. Más bien, pueden tener un método más abstracto para generar datos cuando sea necesario.

  • Debido Controllera que contendrá información adicional que los usuarios pueden no querer conservar, no debe crearse de forma predeterminada. Debería poder (a) instanciar a Controller con una figura y (b) construir una figura con a Controller.

Casos de uso:

  • Exportar toda la información necesaria

  • Serializar una figura de matplotlib, guardarla y poder volver a ejecutarla más tarde.

  • Cualquier otra fuente que envíe una representación con el formato apropiado a matplotlib para abrir

Ejemplos #

Estos son algunos ejemplos de lo que los controladores deberían poder hacer.

  1. Crea una instancia de una figura de matplotlib a partir de una representación serializada (p. ej., 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. Administre artistas desde el controlador (por ejemplo, Line2D):

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

  3. Exportar representación de figura serializable:

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

Implementación #

  1. Cree Controllerobjetos base que puedan administrar Artistobjetos (p. ej., Hist)

    Comentarios:

    • la inicialización debe ocurrir a través del desempaquetado **, por lo que necesitamos una copia del parámetro de firma de llamada para lo Artistque finalmente estamos tratando de controlar. Desafortunada repetición codificada...

    • en caso de que el adicional **kwargsaceptado por cada uno Artist sea rastreado en elController

    • ¿Cómo Controllersabe qué artista pertenece a dónde? Por ejemplo, ¿necesitamos pasar axesreferencias?

    Progreso:

  2. Escriba los protocolos para Controlleractualizar el modelo.

    Comentarios:

    • ¿Cómo se deben tratar los contenedores? Por ejemplo, ¿qué sucede con los parches antiguos cuando volvemos a clasificar un histograma?

    • en el enlace de (1), la línea anterior se destruye por completo y se vuelve a dibujar, ¿y si algo hace referencia a ella?

  3. Crear método mediante el cual se puede ensamblar un objeto json desde el Controllers

  4. Tratar con la serialización de los aspectos no serializables de una figura (por ejemplo, ¿transformaciones no afines?)

  5. Ser capaz de instanciar desde una representación serializada

  6. Vuelva a implementar el método pyplot y Axes existente, por ejemplo, pyplot.histy Axes.histen términos de la nueva clase de controlador.

> @theengineer: en el n. ° 2 anterior, ¿qué quiere decir con obtener actualizaciones de cada uno Artist?

^ Sí. No Controller debería ser necesario actualizarlo. Esto solo sucede en el #3. Borra los comentarios cuando veas esto.

Compatibilidad con versiones anteriores #

  • el decapado cambiará

  • las transformaciones no afines requerirán un método de decapado definido

Alternativas #

PR #3150 sugirió agregar semántica adjuntando de forma parasitaria contenedores adicionales a objetos de hachas. Esta es una solución más completa con lo que debería ser un marco más desarrollado/flexible/potente.