-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
MEP25
Table of Contents
.. author:: Andrew Seier
This MEP template is a guideline of the sections that a MEP should contain. Extra sections may be added if appropriate, and unnecessary sections may be noted as such.
Discussion
- development branches:
- related pull requests:
This MEP aims at adding a serializable Controller objects to act as an Artist managers. Users would then communicate changes to an Artist via a Controller. In this way, functionality of the Controller objects may be added incrementally since each Artist is still responsible for drawing everything. The goal is to create an API that is usable both by graphing libraries requiring high-level descriptions of figures and libraries requiring low-level interpretations.
Matplotlib is a core plotting engine with an API that many users already understand. It's difficult/impossible for other graphing libraries to (1) get a complete figure description, (2) output raw data from the figure object as the user has provided it, (3) understand the semantics of the figure objects without heuristics, and (4) give matplotlib a complete figure description to visualize. In addition, because an Artist has no conception of its own semantics within the figure, it's difficult to interact with them in a natural way.
In this sense, matplotlib will adopt a standard Model-View-Controller (MVC) framework. The Model will be the user defined data, style, and semantics. The Views are the ensemble of each individual Artist, which are responsible for producing the final image based on the model. The Controller will be the Controller object managing its set of Artist objects.
The Controller must be able to export the information that it's carrying about the figure on command, perhaps via a to_json method or similar. Because it would be extremely extraneous to duplicate all of the information in the model with the controller, only user-specified information (data + style) are explicitly kept. If a user wants more information (defaults) from the view/model, it should be able to query for it.
Additional Notes:
* The raw data does not necessarily need to be a list, ndarray, etc. Rather, it can more abstractly just have a method to yield data when needed.
Use Cases: * Export all necessary information to recreate a matplotlib representation as json * Serializing a matplotlib figure, saving it, and being able to rerun later. * Any other source sending an appropriately formatted representation to matplotlib to open
- Create base
Controllerobjects that are able to manageArtistobjects (e.g.,Hist) - Write in protocols for the
Controllerto both update the model and get updates from eachArtistit knows about. - Create method by which a json object can be assembled from the
Controllers - Deal with serializing the unserializable aspects of a figure (e.g., non-affine transforms?)
- Be able to instantiate from a serialized representation
- pickling will change
- non-affine transformations will require a defined pickling method
PR #3150 suggested adding semantics by parasitically attaching extra containers to axes objects. This is a more complete solution with what should be a more developed/flexible/powerful framework.