[Matplotlib-devel] (no subject)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Matplotlib-devel] (no subject)

Daniel McNeela
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

tcaswell
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Daniel McNeela
Basically I'm adding a "layer" construct to the Axes model that allows users to define groups of Matplotlib artists that can be manipulated, hidden, displayed, styled, etc. in tandem without affecting those artists which are on other layers. It's sort of analogous to the way in which layers work in Photoshop.

The issue with simply subclassing the Matplotlib Axes is that I want my subclass to fully integrate with pyplot and other modules. For example, if a user has my module imported and runs

>>> fig = plt.figure()
>>> subplot = plt.subplot(111)

I'd like for subplot to be an instance of my subclassed Axes rather than of the default one provided by Matplotlib.

On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <[hidden email]> wrote:
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Federico Ariza-2

I have done similar things (hiding groups of artists) using the tool manager and custom build tools.

In general I just use the gid property of each artist to keep track of different groups and on trigger I hide a specific group.

Also I use it to pop-up an artist-styler to change colors, linestyle etc...

It is indirect but allows to perform operations without touching base classes.

I know this is not what you asked but hope it helps

Federico

On Jun 5, 2016 10:38 PM, "Daniel McNeela" <[hidden email]> wrote:
Basically I'm adding a "layer" construct to the Axes model that allows users to define groups of Matplotlib artists that can be manipulated, hidden, displayed, styled, etc. in tandem without affecting those artists which are on other layers. It's sort of analogous to the way in which layers work in Photoshop.

The issue with simply subclassing the Matplotlib Axes is that I want my subclass to fully integrate with pyplot and other modules. For example, if a user has my module imported and runs

>>> fig = plt.figure()
>>> subplot = plt.subplot(111)

I'd like for subplot to be an instance of my subclassed Axes rather than of the default one provided by Matplotlib.

On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <[hidden email]> wrote:
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

matplotlib - devel mailing list
Hi Daniel,
I like your ideas.  As Fedrico said, the group part has already exists, see http://matplotlib.org/examples/user_interfaces/toolmanager.html for an example of this, the toolmanager part we still consider as experimental until at least 2.1 when we hope to have gotten it working with all backends together with http://matplotlib.org/devel/MEP/MEP27.html, refactoring the FigureManager so as to decouple pyplot from the backends, a project that I have been working on.

The other parts, http://matplotlib.org/devel/MEP/MEP26.html which looks at creating Cascading Artist Style Sheets, based upon the CSS language spec for websites.  I don't think anyone has started working on this, and may need some more definition and working out; then I started creating another MEP to figure out how to refactor the Axes and related classes into a more coherent and readably understandable structure, you can see the limited progress i have made at defining the document here... https://github.com/matplotlib/matplotlib/pull/5029 I have a few more ideas I want to put into this, just needing to find time to get back to it, probably once we have the backend refactor finished.

Of course, matplotlib works as a fully opensource project, fully collaborative, so any source code changes you would like to see, make them in a fork, and PR them back to the matplotlib (or as I got started, forking Federico's toolmanager fork, and PRing back to him and his PR before merging into master, as part of MEP22).  And of course, feel free to get involved in any of this stuff if you like it, the more the merrier :).

Best,
OceanWolf


From: Federico Ariza <[hidden email]>
To: Daniel McNeela <[hidden email]>
Cc: matplotlib development list <[hidden email]>
Sent: Monday, 6 June 2016, 12:19
Subject: Re: [Matplotlib-devel] (no subject)

I have done similar things (hiding groups of artists) using the tool manager and custom build tools.
In general I just use the gid property of each artist to keep track of different groups and on trigger I hide a specific group.
Also I use it to pop-up an artist-styler to change colors, linestyle etc...
It is indirect but allows to perform operations without touching base classes.
I know this is not what you asked but hope it helps
Federico
On Jun 5, 2016 10:38 PM, "Daniel McNeela" <[hidden email]> wrote:
Basically I'm adding a "layer" construct to the Axes model that allows users to define groups of Matplotlib artists that can be manipulated, hidden, displayed, styled, etc. in tandem without affecting those artists which are on other layers. It's sort of analogous to the way in which layers work in Photoshop.

The issue with simply subclassing the Matplotlib Axes is that I want my subclass to fully integrate with pyplot and other modules. For example, if a user has my module imported and runs

>>> fig = plt.figure()
>>> subplot = plt.subplot(111)

I'd like for subplot to be an instance of my subclassed Axes rather than of the default one provided by Matplotlib.

On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <[hidden email]> wrote:
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel



_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Daniel McNeela
Thank you OceanWolf and Federico. I was previously unaware of the gid property of Artists and the new ToolManager classes, and it looks like what I have been doing is pretty similar to what is contained therein. You can take a look at my progress here: 


(The code is a bit messy as I haven't gotten around to cleaning it up yet.)

Basically I just have a layer dictionary associated with each axes in which I can update, set, and delete properties. If you interactively run the two examples included in that folder, you can type in commands at the Python interpreter and watch the plots change in response. For example, with the basic_layer_demo, you could run the following

>>> subplots.hide("cubic")    # Hides the 'cubic' layer while keeping the 'quadratic' layer displayed

>>> subplots.show("cubic")    # Redisplays the "cubic" layer

>>> subplots.set_style("cubic", 'ro')    # Changes the style of the cubic layer
>>> subplots.build_layers()         # Rebuilds the layers so that the new styling takes effect

Is this something that you think would have utility if directly incorporated into Matplotlib's axes class, or is better to just have it built out on top as is done with the ToolManager classes?

On Mon, Jun 6, 2016 at 5:34 AM, OceanWolf <[hidden email]> wrote:
Hi Daniel,
I like your ideas.  As Fedrico said, the group part has already exists, see http://matplotlib.org/examples/user_interfaces/toolmanager.html for an example of this, the toolmanager part we still consider as experimental until at least 2.1 when we hope to have gotten it working with all backends together with http://matplotlib.org/devel/MEP/MEP27.html, refactoring the FigureManager so as to decouple pyplot from the backends, a project that I have been working on.

The other parts, http://matplotlib.org/devel/MEP/MEP26.html which looks at creating Cascading Artist Style Sheets, based upon the CSS language spec for websites.  I don't think anyone has started working on this, and may need some more definition and working out; then I started creating another MEP to figure out how to refactor the Axes and related classes into a more coherent and readably understandable structure, you can see the limited progress i have made at defining the document here... https://github.com/matplotlib/matplotlib/pull/5029 I have a few more ideas I want to put into this, just needing to find time to get back to it, probably once we have the backend refactor finished.

Of course, matplotlib works as a fully opensource project, fully collaborative, so any source code changes you would like to see, make them in a fork, and PR them back to the matplotlib (or as I got started, forking Federico's toolmanager fork, and PRing back to him and his PR before merging into master, as part of MEP22).  And of course, feel free to get involved in any of this stuff if you like it, the more the merrier :).

Best,
OceanWolf


From: Federico Ariza <[hidden email]>
To: Daniel McNeela <[hidden email]>
Cc: matplotlib development list <[hidden email]>
Sent: Monday, 6 June 2016, 12:19
Subject: Re: [Matplotlib-devel] (no subject)

I have done similar things (hiding groups of artists) using the tool manager and custom build tools.
In general I just use the gid property of each artist to keep track of different groups and on trigger I hide a specific group.
Also I use it to pop-up an artist-styler to change colors, linestyle etc...
It is indirect but allows to perform operations without touching base classes.
I know this is not what you asked but hope it helps
Federico
On Jun 5, 2016 10:38 PM, "Daniel McNeela" <[hidden email]> wrote:
Basically I'm adding a "layer" construct to the Axes model that allows users to define groups of Matplotlib artists that can be manipulated, hidden, displayed, styled, etc. in tandem without affecting those artists which are on other layers. It's sort of analogous to the way in which layers work in Photoshop.

The issue with simply subclassing the Matplotlib Axes is that I want my subclass to fully integrate with pyplot and other modules. For example, if a user has my module imported and runs

>>> fig = plt.figure()
>>> subplot = plt.subplot(111)

I'd like for subplot to be an instance of my subclassed Axes rather than of the default one provided by Matplotlib.

On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <[hidden email]> wrote:
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel




_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Daniel McNeela
I actually was able to achieve the desired behavior by creating my own projection based on my modified Axes class and adding that projection to the projection registry.

On Mon, Jun 6, 2016 at 11:01 AM, Daniel McNeela <[hidden email]> wrote:
Thank you OceanWolf and Federico. I was previously unaware of the gid property of Artists and the new ToolManager classes, and it looks like what I have been doing is pretty similar to what is contained therein. You can take a look at my progress here: 


(The code is a bit messy as I haven't gotten around to cleaning it up yet.)

Basically I just have a layer dictionary associated with each axes in which I can update, set, and delete properties. If you interactively run the two examples included in that folder, you can type in commands at the Python interpreter and watch the plots change in response. For example, with the basic_layer_demo, you could run the following

>>> subplots.hide("cubic")    # Hides the 'cubic' layer while keeping the 'quadratic' layer displayed

>>> subplots.show("cubic")    # Redisplays the "cubic" layer

>>> subplots.set_style("cubic", 'ro')    # Changes the style of the cubic layer
>>> subplots.build_layers()         # Rebuilds the layers so that the new styling takes effect

Is this something that you think would have utility if directly incorporated into Matplotlib's axes class, or is better to just have it built out on top as is done with the ToolManager classes?

On Mon, Jun 6, 2016 at 5:34 AM, OceanWolf <[hidden email]> wrote:
Hi Daniel,
I like your ideas.  As Fedrico said, the group part has already exists, see http://matplotlib.org/examples/user_interfaces/toolmanager.html for an example of this, the toolmanager part we still consider as experimental until at least 2.1 when we hope to have gotten it working with all backends together with http://matplotlib.org/devel/MEP/MEP27.html, refactoring the FigureManager so as to decouple pyplot from the backends, a project that I have been working on.

The other parts, http://matplotlib.org/devel/MEP/MEP26.html which looks at creating Cascading Artist Style Sheets, based upon the CSS language spec for websites.  I don't think anyone has started working on this, and may need some more definition and working out; then I started creating another MEP to figure out how to refactor the Axes and related classes into a more coherent and readably understandable structure, you can see the limited progress i have made at defining the document here... https://github.com/matplotlib/matplotlib/pull/5029 I have a few more ideas I want to put into this, just needing to find time to get back to it, probably once we have the backend refactor finished.

Of course, matplotlib works as a fully opensource project, fully collaborative, so any source code changes you would like to see, make them in a fork, and PR them back to the matplotlib (or as I got started, forking Federico's toolmanager fork, and PRing back to him and his PR before merging into master, as part of MEP22).  And of course, feel free to get involved in any of this stuff if you like it, the more the merrier :).

Best,
OceanWolf


From: Federico Ariza <[hidden email]>
To: Daniel McNeela <[hidden email]>
Cc: matplotlib development list <[hidden email]>
Sent: Monday, 6 June 2016, 12:19
Subject: Re: [Matplotlib-devel] (no subject)

I have done similar things (hiding groups of artists) using the tool manager and custom build tools.
In general I just use the gid property of each artist to keep track of different groups and on trigger I hide a specific group.
Also I use it to pop-up an artist-styler to change colors, linestyle etc...
It is indirect but allows to perform operations without touching base classes.
I know this is not what you asked but hope it helps
Federico
On Jun 5, 2016 10:38 PM, "Daniel McNeela" <[hidden email]> wrote:
Basically I'm adding a "layer" construct to the Axes model that allows users to define groups of Matplotlib artists that can be manipulated, hidden, displayed, styled, etc. in tandem without affecting those artists which are on other layers. It's sort of analogous to the way in which layers work in Photoshop.

The issue with simply subclassing the Matplotlib Axes is that I want my subclass to fully integrate with pyplot and other modules. For example, if a user has my module imported and runs

>>> fig = plt.figure()
>>> subplot = plt.subplot(111)

I'd like for subplot to be an instance of my subclassed Axes rather than of the default one provided by Matplotlib.

On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <[hidden email]> wrote:
Simply sub-classing any of those classes in your code would reasonable.

I am curious about what sort of extensions you are adding?  I think in many cases writing functions that take in `Axes` (or `Figure` if that is the right scope) objects and operate on them.

An example of a project that is sub-classing `Axes` is https://github.com/scls19fr/windrose .

Tom

On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <[hidden email]> wrote:
Hi All,

I'm currently developing a Python package built on top of Matplotlib, and I'd like to add custom functionality to the Axes class while still retaining all of the default Matplotlib syntax and commands. To do this, I'd like to subclass matplotlib.axes.Axes (or possibly matplotlib.axes._base._AxesBase) and add additional class attributes and methods. Ideally, I'd like to do this without forking Matplotlib and directly editing the source so as to maintain compatibility with future Matplotlib releases. I see that in pyplot.py, calls to figure() accept an optional FigureClass argument which I could use to pass a custom subclass of Figure. I was thinking I could subclass Figure such that the subclass overrides methods such as Figure.add_subplot() by calling the superclass's method and passing my custom Axes subclass in as an optional argument. But I'm not sure which methods I'd have to override, or how deep the rabbit hole goes, as Axes objects seem to be generated in a number of places throughout the Matplotlib source.

If anyone who is familiar with the code base might be able to suggest a simple way in which I could accomplish this desired behavior, I would greatly appreciate it! Right now, I'm adding the desired functionality via a function that accepts Matplotlib Axes instances and binds custom attributes/methods to these instances via Python's type.MethodType, but this seems like a rather clunky and un-Pythonic approach to building what will likely be an extensive application.

Thank you in advance for your help!

Best,

Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel





_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel