MEP25: número de serialização

Estado #

rejeitado

Este trabalho é importante, mas este esforço específico estagnou.

Filiais e solicitações pull #

  • ramos de desenvolvimento:

  • solicitações pull relacionadas:

Resumo #

Este MEP visa adicionar Controllerobjetos serializáveis ​​para atuar como Artistgerenciadores. Os usuários então comunicariam as alterações a um Artistpor meio de um arquivo Controller. Dessa forma, a funcionalidade dos Controllerobjetos pode ser adicionada de forma incremental, pois cada Artistum ainda é responsável por desenhar tudo. O objetivo é criar uma API que seja utilizável tanto por bibliotecas de gráficos que requerem descrições de figuras de alto nível quanto por bibliotecas que requerem interpretações de baixo nível.

Descrição detalhada #

Matplotlib é um mecanismo de plotagem central com uma API que muitos usuários já entendem. É difícil/impossível para outras bibliotecas gráficas (1) obter uma descrição completa da figura, (2) produzir dados brutos do objeto da figura conforme o usuário os forneceu, (3) entender a semântica dos objetos da figura sem heurística e ( 4) forneça ao matplotlib uma descrição completa da figura para visualizar. Além disso, como an Artistnão tem concepção de sua própria semântica dentro da figura, é difícil interagir com eles de maneira natural.

Nesse sentido, o matplotlib adotará uma estrutura padrão Model-View-Controller (MVC). O modelo será os dados, estilo e semântica definidos pelo usuário. As Views são o conjunto de cada indivíduo Artist, que são responsáveis ​​por produzir a imagem final baseada no modelo . O Controller será o Controllerobjeto gerenciando seu conjunto de Artistobjetos.

O Controllerdeve ser capaz de exportar as informações que carrega sobre a figura no comando, talvez por meio de um to_jsonmétodo ou similar. Como seria extremamente estranho duplicar todas as informações no modelo com o controlador, apenas as informações especificadas pelo usuário (dados + estilo) são explicitamente mantidas. Se um usuário quiser mais informações (padrão) da visão/modelo, ele poderá consultá-las.

  • Isso pode ser chato de fazer, kwargs não especificados são extraídos do objeto rcParams que, por sua vez, é criado a partir da leitura de um arquivo especificado pelo usuário e pode ser alterado dinamicamente em tempo de execução. Suponho que poderíamos manter um ditado de padrões padrão e comparar com isso. Não está claro como isso irá interagir com a folha de estilo [[MEP26]] - @tacaswell

Notas Adicionais:

  • Os "dados brutos" não precisam necessariamente ser um list, ndarray, etc. Em vez disso, podem ter apenas um método mais abstrato para fornecer dados quando necessário.

  • Como o Controllerirá conter informações extras que os usuários podem não querer manter, ele não deve ser criado por padrão. Você deve ser capaz de (a) instanciar a Controller com uma figura e (b) construir uma figura com a Controller.

Casos de uso:

  • Exporte todas as informações necessárias

  • Serializar uma figura matplotlib, salvá-la e poder executá-la novamente mais tarde.

  • Qualquer outra fonte enviando uma representação formatada apropriadamente para matplotlib para abrir

Exemplos #

Aqui estão alguns exemplos do que os controladores devem ser capazes de fazer.

  1. Instancie uma figura matplotlib a partir de uma representação serializada (por exemplo, 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. Gerenciar artistas do controlador (por exemplo, Line2D):

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

  3. Exportar representação de figura serializável:

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

Implementação #

  1. Crie Controllerobjetos base que são capazes de gerenciar Artistobjetos (por exemplo, Hist)

    Comentários:

    • a inicialização deve ocorrer por meio de unpacking **, portanto, precisamos de uma cópia do parâmetro de assinatura de chamada para o Artistque estamos tentando controlar. Repetição codificada infeliz...

    • caso os adicionais **kwargsaceitos por cada um Artist sejam rastreados noController

    • como Controllersaber qual artista pertence a onde? Por exemplo, precisamos passar axesreferências?

    Progresso:

  2. Escreva os protocolos para Controlleratualizar o modelo.

    Comentários:

    • como os contêineres devem ser tratados? Por exemplo, o que acontece com patches antigos quando redefinimos um histograma?

    • no link de (1), a linha antiga é completamente destruída e redesenhada, e se algo estiver fazendo referência a ela?

  3. Criar método pelo qual um objeto json pode ser montado a partir do Controllers

  4. Lidar com a serialização dos aspectos não serializáveis ​​de uma figura (por exemplo, transformações não afins?)

  5. Ser capaz de instanciar a partir de uma representação serializada

  6. Reimplemente o pyplot existente e o método Axes, por exemplo, pyplot.histe Axes.histem termos da nova classe do controlador.

> @theengineer: no item 2 acima, o que você quer dizer com obter atualizações de cada um Artist?

^ Sim. O Controller não deve precisar ser atualizado. Isso só acontece no #3. Exclua os comentários quando vir isso.

Compatibilidade com versões anteriores #

  • decapagem vai mudar

  • transformações não afins exigirão um método de decapagem definido

Alternativas #

O PR #3150 sugeriu adicionar semântica anexando parasiticamente contêineres extras a objetos axes. Esta é uma solução mais completa com o que deveria ser um framework mais desenvolvido/flexível/poderoso.