Menu
▾
▴
matplotlib-devel
|
From: Tony Yu <ts...@gm...> - 2013-07-09 05:19:50
|
This is an idea that's been kicking around in my head for awhile. Basically, the Axes class is way too expansive. Nelle made a major step in the right direction with a PR that split it up into plotting and non-plotting methods: https://github.com/matplotlib/matplotlib/pull/1931/files What I'd like to see is something that further separates plotting methods into many smaller sub-modules/-packages. Organizing the code this way would make it easier (for me at least) to read, understand, and make changes to the code. I think that this could be done in an API-compatible way. In fact, a few of the plotting methods are already implemented this way: In other words, the bulk of the methods are implemented as functions outside of Axes, and the Axes methods that are just thin wrappers around those functions (or classes). See, for example, `streamplot`, `barbs`, and `quiver` methods The examples mentioned above simply take the axes as the first parameter. Here's the Axes-method definition of `quiver`, for example: def quiver(self, *args, **kw): ... q = mquiver.Quiver(self, *args, **kw) ... return q (might be a good idea to add a decorator to maintain the function signature and docstring) This should work for any of the plotting methods (I would imagine). Another alternative is for all these plotting functions to have an `ax` (or some other spelling) keyword argument that defaults to None and then have a line in every function that does something like ax = ax if ax is not None else plt.gca() If I'm not mistaken, this would allow pyplot functions to be even thinner wrappers around these newly extracted functions. (In some cases, it might just be a simple import from the the new sub-package/-module into the `pyplot` namespace). I haven't sat down and thought through all the details of such a change, but I wanted to throw it out there to see if anything sticks. Cheers, -Tony |
|
From: Eric F. <ef...@ha...> - 2013-07-09 06:25:02
|
On 2013/07/08 7:19 PM, Tony Yu wrote: > This is an idea that's been kicking around in my head for awhile. > Basically, the Axes class is way too expansive. Nelle made a major step > in the right direction with a PR that split it up into plotting and > non-plotting methods: > > https://github.com/matplotlib/matplotlib/pull/1931/files > > What I'd like to see is something that further separates plotting > methods into many smaller sub-modules/-packages. Organizing the code > this way would make it easier (for me at least) to read, understand, and > make changes to the code. > > I think that this could be done in an API-compatible way. In fact, a few > of the plotting methods are already implemented this way: In other > words, the bulk of the methods are implemented as functions outside of > Axes, and the Axes methods that are just thin wrappers around those > functions (or classes). See, for example, `streamplot`, `barbs`, and > `quiver` methods I agree. I would like to see logical groups of plot types broken out into modules. > > The examples mentioned above simply take the axes as the first > parameter. Here's the Axes-method definition of `quiver`, for example: > > def quiver(self, *args, **kw): > ... > q = mquiver.Quiver(self, *args, **kw) > ... > return q > > (might be a good idea to add a decorator to maintain the function > signature and docstring) > > This should work for any of the plotting methods (I would imagine). > Another alternative is for all these plotting functions to have an `ax` > (or some other spelling) keyword argument that defaults to None and then > have a line in every function that does something like > > ax = ax if ax is not None else plt.gca() > > If I'm not mistaken, this would allow pyplot functions to be even > thinner wrappers around these newly extracted functions. (In some cases, > it might just be a simple import from the the new sub-package/-module > into the `pyplot` namespace). > This would require pyplot to be imported by everything, wouldn't it? That would completely defeat the strategy of having an OO level that doesn't know about pyplot at all, and then having pyplot be the thin top layer. Eric > I haven't sat down and thought through all the details of such a change, > but I wanted to throw it out there to see if anything sticks. > > Cheers, > -Tony > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Tony Yu <ts...@gm...> - 2013-07-10 01:39:35
|
On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing <ef...@ha...> wrote: <snip> This would require pyplot to be imported by everything, wouldn't it? > That would completely defeat the strategy of having an OO level that > doesn't know about pyplot at all, and then having pyplot be the thin top > layer. > Ahh, you're right! Like I said, I haven't really sat down and thought through all the details :) > > Eric > > > I haven't sat down and thought through all the details of such a change, > > but I wanted to throw it out there to see if anything sticks. > > > > Cheers, > > -Tony > > |
|
From: Nelle V. <nel...@gm...> - 2013-07-09 06:43:42
|
On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote: > On 2013/07/08 7:19 PM, Tony Yu wrote: >> This is an idea that's been kicking around in my head for awhile. >> Basically, the Axes class is way too expansive. Nelle made a major step >> in the right direction with a PR that split it up into plotting and >> non-plotting methods: >> >> https://github.com/matplotlib/matplotlib/pull/1931/files >> >> What I'd like to see is something that further separates plotting >> methods into many smaller sub-modules/-packages. Organizing the code >> this way would make it easier (for me at least) to read, understand, and >> make changes to the code. >> >> I think that this could be done in an API-compatible way. In fact, a few >> of the plotting methods are already implemented this way: In other >> words, the bulk of the methods are implemented as functions outside of >> Axes, and the Axes methods that are just thin wrappers around those >> functions (or classes). See, for example, `streamplot`, `barbs`, and >> `quiver` methods > > I agree. I would like to see logical groups of plot types broken out > into modules. That's the second step in the refactoring of the axes module. We now have to discuss how to organize plots in subtypes that make sense. At Scipy, we discussed a bit about it, and we think it should follow the same organization as the gallery, but I don't know whether the gallery reorganization is logical enough right now to start the refactoring straight away. Should we discuss about this here, or in a ticket? >> >> The examples mentioned above simply take the axes as the first >> parameter. Here's the Axes-method definition of `quiver`, for example: >> >> def quiver(self, *args, **kw): >> ... >> q = mquiver.Quiver(self, *args, **kw) >> ... >> return q >> >> (might be a good idea to add a decorator to maintain the function >> signature and docstring) >> >> This should work for any of the plotting methods (I would imagine). >> Another alternative is for all these plotting functions to have an `ax` >> (or some other spelling) keyword argument that defaults to None and then >> have a line in every function that does something like >> >> ax = ax if ax is not None else plt.gca() >> >> If I'm not mistaken, this would allow pyplot functions to be even >> thinner wrappers around these newly extracted functions. (In some cases, >> it might just be a simple import from the the new sub-package/-module >> into the `pyplot` namespace). >> > > This would require pyplot to be imported by everything, wouldn't it? > That would completely defeat the strategy of having an OO level that > doesn't know about pyplot at all, and then having pyplot be the thin top > layer. > > Eric > >> I haven't sat down and thought through all the details of such a change, >> but I wanted to throw it out there to see if anything sticks. >> >> Cheers, >> -Tony >> >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Thomas A C. <tca...@uc...> - 2013-07-09 15:40:39
|
I second Eric's concern about pyplot being imported into everything. It will really mess up the people that are embedding matplotlib into guis because pyplot starts up gui mainloops if you are using an interactive backend. There is a genre of question on SO that is 'why isn't pyplot playing nice with my gui'. Tom On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux <nel...@gm...>wrote: > On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote: > > On 2013/07/08 7:19 PM, Tony Yu wrote: > >> This is an idea that's been kicking around in my head for awhile. > >> Basically, the Axes class is way too expansive. Nelle made a major step > >> in the right direction with a PR that split it up into plotting and > >> non-plotting methods: > >> > >> https://github.com/matplotlib/matplotlib/pull/1931/files > >> > >> What I'd like to see is something that further separates plotting > >> methods into many smaller sub-modules/-packages. Organizing the code > >> this way would make it easier (for me at least) to read, understand, and > >> make changes to the code. > >> > >> I think that this could be done in an API-compatible way. In fact, a few > >> of the plotting methods are already implemented this way: In other > >> words, the bulk of the methods are implemented as functions outside of > >> Axes, and the Axes methods that are just thin wrappers around those > >> functions (or classes). See, for example, `streamplot`, `barbs`, and > >> `quiver` methods > > > > I agree. I would like to see logical groups of plot types broken out > > into modules. > > That's the second step in the refactoring of the axes module. > We now have to discuss how to organize plots in subtypes that make > sense. At Scipy, we discussed a bit about it, and we think it should > follow the same organization as the gallery, but I don't know whether > the gallery reorganization is logical enough right now to start the > refactoring straight away. > > Should we discuss about this here, or in a ticket? > > >> > >> The examples mentioned above simply take the axes as the first > >> parameter. Here's the Axes-method definition of `quiver`, for example: > >> > >> def quiver(self, *args, **kw): > >> ... > >> q = mquiver.Quiver(self, *args, **kw) > >> ... > >> return q > >> > >> (might be a good idea to add a decorator to maintain the function > >> signature and docstring) > >> > >> This should work for any of the plotting methods (I would imagine). > >> Another alternative is for all these plotting functions to have an `ax` > >> (or some other spelling) keyword argument that defaults to None and then > >> have a line in every function that does something like > >> > >> ax = ax if ax is not None else plt.gca() > >> > >> If I'm not mistaken, this would allow pyplot functions to be even > >> thinner wrappers around these newly extracted functions. (In some cases, > >> it might just be a simple import from the the new sub-package/-module > >> into the `pyplot` namespace). > >> > > > > This would require pyplot to be imported by everything, wouldn't it? > > That would completely defeat the strategy of having an OO level that > > doesn't know about pyplot at all, and then having pyplot be the thin top > > layer. > > > > Eric > > > >> I haven't sat down and thought through all the details of such a change, > >> but I wanted to throw it out there to see if anything sticks. > >> > >> Cheers, > >> -Tony > >> > >> > >> > ------------------------------------------------------------------------------ > >> See everything from the browser to the database with AppDynamics > >> Get end-to-end visibility with application monitoring from AppDynamics > >> Isolate bottlenecks and diagnose root cause in seconds. > >> Start your free trial of AppDynamics Pro today! > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > >> > >> > >> > >> _______________________________________________ > >> Matplotlib-devel mailing list > >> Mat...@li... > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >> > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Thomas A Caswell PhD Candidate University of Chicago Nagel and Gardel labs tca...@uc... jfi.uchicago.edu/~tcaswell o: 773.702.7204 |
|
From: Tony Yu <ts...@gm...> - 2013-07-10 01:54:58
|
On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux <nel...@gm...>wrote: > On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote: > > On 2013/07/08 7:19 PM, Tony Yu wrote: > >> This is an idea that's been kicking around in my head for awhile. > >> Basically, the Axes class is way too expansive. Nelle made a major step > >> in the right direction with a PR that split it up into plotting and > >> non-plotting methods: > >> > >> https://github.com/matplotlib/matplotlib/pull/1931/files > >> > >> What I'd like to see is something that further separates plotting > >> methods into many smaller sub-modules/-packages. Organizing the code > >> this way would make it easier (for me at least) to read, understand, and > >> make changes to the code. > >> > >> I think that this could be done in an API-compatible way. In fact, a few > >> of the plotting methods are already implemented this way: In other > >> words, the bulk of the methods are implemented as functions outside of > >> Axes, and the Axes methods that are just thin wrappers around those > >> functions (or classes). See, for example, `streamplot`, `barbs`, and > >> `quiver` methods > > > > I agree. I would like to see logical groups of plot types broken out > > into modules. > > That's the second step in the refactoring of the axes module. > We now have to discuss how to organize plots in subtypes that make > sense. At Scipy, we discussed a bit about it, and we think it should > follow the same organization as the gallery, but I don't know whether > the gallery reorganization is logical enough right now to start the > refactoring straight away. > I knew I should have dropped by the matplotlib sprints :) The gallery categories really aren't that logical, but as long as the functions aren't meant to be directly imported from their sub-modules (instead you would use the Axes method or pyplot function), then nothing needs to be permanent, right? > > Should we discuss about this here, or in a ticket? > It's probably easier to discuss on a new ticket. Cheers, -Tony |
|
From: Anton A. <ant...@gm...> - 2013-07-10 11:11:41
|
Eric Firing <efiring@...> writes:
> This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
Requiring pyplot isn't necessary, instead one may merely check if it's
available. The following is what we do in a similar situation:
try:
fake_fig = matplotlib.pyplot.figure()
except AttributeError:
msg = 'matplotlib.pyplot is unavailable. Execute `import ' \
'matplotlib.pyplot` or use a different output mode.'
raise RuntimeError(msg)
(obviously, one can substitute figure() call to gca())
Anton
>
> Eric
>
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
> >
> >
> > ------------------------------------------------------------------------
------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
> --------------------------------------------------------------------------
----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
>
|
|
From: Eric F. <ef...@ha...> - 2013-07-10 17:40:58
|
On 2013/07/10 1:11 AM, Anton Akhmerov wrote: > Eric Firing <efiring@...> writes: > >> This would require pyplot to be imported by everything, wouldn't it? >> That would completely defeat the strategy of having an OO level that >> doesn't know about pyplot at all, and then having pyplot be the thin top >> layer. > > Requiring pyplot isn't necessary, instead one may merely check if it's > available. The following is what we do in a similar situation: > > try: > fake_fig = matplotlib.pyplot.figure() > except AttributeError: > msg = 'matplotlib.pyplot is unavailable. Execute `import ' \ > 'matplotlib.pyplot` or use a different output mode.' > raise RuntimeError(msg) > > (obviously, one can substitute figure() call to gca()) > > Anton Anton, Yes, I have done things like that in my own code, and basemap has a similar ability to call gca() when an Axes is not supplied. One can even perform the pyplot import on an as-needed basis instead of raising an error. Nevetheless, it still represents what I view as a big change in mpl design, scrambling the state machine pyplot layer into the OO layer. Sometimes this sort of thing is good, sometimes it isn't. In the present case, I am far from convinced that it would be good. I don't see any real benefit at all over the present design. I think that for the sanity of the developers, if nothing else, it is important to maintain some clear layering and hierarchy. Eric |
|
From: Anton A. <ant...@gm...> - 2013-07-11 11:13:03
|
Eric Firing <efiring@...> writes: > > Anton, > > Yes, I have done things like that in my own code, and basemap has a > similar ability to call gca() when an Axes is not supplied. One can > even perform the pyplot import on an as-needed basis instead of raising > an error. Nevetheless, it still represents what I view as a big change > in mpl design, scrambling the state machine pyplot layer into the OO > layer. Sometimes this sort of thing is good, sometimes it isn't. In > the present case, I am far from convinced that it would be good. I > don't see any real benefit at all over the present design. I think that > for the sanity of the developers, if nothing else, it is important to > maintain some clear layering and hierarchy. > > Eric > I completely agree with that, and I just wanted to point out the possibility. With the proposed separation of the plots to a separate module, I think, the reasonable thing for pyplot would be to wrap the corresponding plot functions by feeding gca into the axis argument. PS for what I think, pyplot right now is way too thick of a layer, obstructing an API use of backends. Anton |
|
From: Nelle V. <nel...@gm...> - 2013-07-11 11:31:19
|
FYI, I have started the refactoring we discussed at scipy. I think what tony is suggesting is the same thing. I've created a "work in progress" pull request: https://github.com/matplotlib/matplotlib/pull/2213 In the refactoring we discussed at Scipy, we did not mention the pyplots wrapper at all. It does not impact pyplot or the axes module at all as it doesn't change the API at all. If we want to do something more in depth that impacts the API, I think it would be worth writing a MEP. Thanks, N On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...> wrote: > Eric Firing <efiring@...> writes: >> >> Anton, >> >> Yes, I have done things like that in my own code, and basemap has a >> similar ability to call gca() when an Axes is not supplied. One can >> even perform the pyplot import on an as-needed basis instead of raising >> an error. Nevetheless, it still represents what I view as a big change >> in mpl design, scrambling the state machine pyplot layer into the OO >> layer. Sometimes this sort of thing is good, sometimes it isn't. In >> the present case, I am far from convinced that it would be good. I >> don't see any real benefit at all over the present design. I think that >> for the sanity of the developers, if nothing else, it is important to >> maintain some clear layering and hierarchy. >> >> Eric >> > > I completely agree with that, and I just wanted to point out the possibility. > With the proposed separation of the plots to a separate module, I think, the > reasonable thing for pyplot would be to wrap the corresponding plot functions > by feeding gca into the axis argument. > > PS for what I think, pyplot right now is way too thick of a layer, > obstructing an API use of backends. > > Anton > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Tony Yu <ts...@gm...> - 2013-07-12 03:48:33
|
Nelle, this is great! Thanks for getting the ball rolling! Cheers, -Tony On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux <nel...@gm...>wrote: > FYI, I have started the refactoring we discussed at scipy. I think > what tony is suggesting is the same thing. > > I've created a "work in progress" pull request: > https://github.com/matplotlib/matplotlib/pull/2213 > > In the refactoring we discussed at Scipy, we did not mention the > pyplots wrapper at all. It does not impact pyplot or the axes module > at all as it doesn't change the API at all. If we want to do something > more in depth that impacts the API, I think it would be worth writing > a MEP. > > Thanks, > N > > > On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...> wrote: > > Eric Firing <efiring@...> writes: > >> > >> Anton, > >> > >> Yes, I have done things like that in my own code, and basemap has a > >> similar ability to call gca() when an Axes is not supplied. One can > >> even perform the pyplot import on an as-needed basis instead of raising > >> an error. Nevetheless, it still represents what I view as a big change > >> in mpl design, scrambling the state machine pyplot layer into the OO > >> layer. Sometimes this sort of thing is good, sometimes it isn't. In > >> the present case, I am far from convinced that it would be good. I > >> don't see any real benefit at all over the present design. I think that > >> for the sanity of the developers, if nothing else, it is important to > >> maintain some clear layering and hierarchy. > >> > >> Eric > >> > > > > I completely agree with that, and I just wanted to point out the > possibility. > > With the proposed separation of the plots to a separate module, I think, > the > > reasonable thing for pyplot would be to wrap the corresponding plot > functions > > by feeding gca into the axis argument. > > > > PS for what I think, pyplot right now is way too thick of a layer, > > obstructing an API use of backends. > > > > Anton > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Michael D. <md...@st...> - 2013-07-17 13:16:59
|
Yes. This is great work! Just to chime in (after having been away for most of this conversation) --> I think we can do this reorganization now without introducing any implicit (or otherwise) use of gca()/pyplot stuff in the Axes class methods. Refactoring how the pyplot wrapper is done can be done as a separate project at a later time (or even in parallel if someone wants to, since all of Nelle's work at the end of the day doesn't change the Axes interface). My only other comment (and I mentioned this in PR #2213 as well) is that having the short stub functions in the Axes class in addition to the actual implementations elsewhere introduces a new synchronization/maintenance problem between the two. Maybe it makes sense to merely add the implementation functions to the Axes class namespace dynamically. Magical, sure, but should have ultimately the same result as far as introspection, autocompletion and other IPython goodness is concerned. Mike On 07/11/2013 11:47 PM, Tony Yu wrote: > Nelle, this is great! Thanks for getting the ball rolling! > > Cheers, > -Tony > > > On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux > <nel...@gm... <mailto:nel...@gm...>> wrote: > > FYI, I have started the refactoring we discussed at scipy. I think > what tony is suggesting is the same thing. > > I've created a "work in progress" pull request: > https://github.com/matplotlib/matplotlib/pull/2213 > > In the refactoring we discussed at Scipy, we did not mention the > pyplots wrapper at all. It does not impact pyplot or the axes module > at all as it doesn't change the API at all. If we want to do something > more in depth that impacts the API, I think it would be worth writing > a MEP. > > Thanks, > N > > > On 11 July 2013 13:12, Anton Akhmerov <ant...@gm... > <mailto:ant...@gm...>> wrote: > > Eric Firing <efiring@...> writes: > >> > >> Anton, > >> > >> Yes, I have done things like that in my own code, and basemap has a > >> similar ability to call gca() when an Axes is not supplied. > One can > >> even perform the pyplot import on an as-needed basis instead of > raising > >> an error. Nevetheless, it still represents what I view as a big > change > >> in mpl design, scrambling the state machine pyplot layer into > the OO > >> layer. Sometimes this sort of thing is good, sometimes it > isn't. In > >> the present case, I am far from convinced that it would be good. I > >> don't see any real benefit at all over the present design. I > think that > >> for the sanity of the developers, if nothing else, it is > important to > >> maintain some clear layering and hierarchy. > >> > >> Eric > >> > > > > I completely agree with that, and I just wanted to point out the > possibility. > > With the proposed separation of the plots to a separate module, > I think, the > > reasonable thing for pyplot would be to wrap the corresponding > plot functions > > by feeding gca into the axis argument. > > > > PS for what I think, pyplot right now is way too thick of a layer, > > obstructing an API use of backends. > > > > Anton > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from > AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > <mailto:Mat...@li...> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Eric F. <ef...@ha...> - 2013-07-17 20:57:45
|
On 2013/07/17 3:14 AM, Michael Droettboom wrote: > Yes. This is great work! > > Just to chime in (after having been away for most of this conversation) --> > > I think we can do this reorganization now without introducing any > implicit (or otherwise) use of gca()/pyplot stuff in the Axes class > methods. Refactoring how the pyplot wrapper is done can be done as a > separate project at a later time (or even in parallel if someone wants > to, since all of Nelle's work at the end of the day doesn't change the > Axes interface). > > My only other comment (and I mentioned this in PR #2213 as well) is that > having the short stub functions in the Axes class in addition to the > actual implementations elsewhere introduces a new > synchronization/maintenance problem between the two. Maybe it makes > sense to merely add the implementation functions to the Axes class > namespace dynamically. Magical, sure, but should have ultimately the > same result as far as introspection, autocompletion and other IPython > goodness is concerned. > > Mike Mike, One other option is to have the new private modules include mixin classes from which Axes would inherit methods. There would be a lot of mixins, and this would be an example of the dreaded multiple inheritance, but it would be simple and explicit, with no magic. Eric |
|
From: Michael D. <md...@st...> - 2013-07-18 13:29:59
|
On 07/17/2013 04:57 PM, Eric Firing wrote: > On 2013/07/17 3:14 AM, Michael Droettboom wrote: >> Yes. This is great work! >> >> Just to chime in (after having been away for most of this conversation) --> >> >> I think we can do this reorganization now without introducing any >> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class >> methods. Refactoring how the pyplot wrapper is done can be done as a >> separate project at a later time (or even in parallel if someone wants >> to, since all of Nelle's work at the end of the day doesn't change the >> Axes interface). >> >> My only other comment (and I mentioned this in PR #2213 as well) is that >> having the short stub functions in the Axes class in addition to the >> actual implementations elsewhere introduces a new >> synchronization/maintenance problem between the two. Maybe it makes >> sense to merely add the implementation functions to the Axes class >> namespace dynamically. Magical, sure, but should have ultimately the >> same result as far as introspection, autocompletion and other IPython >> goodness is concerned. >> >> Mike > Mike, > > One other option is to have the new private modules include mixin > classes from which Axes would inherit methods. There would be a lot of > mixins, and this would be an example of the dreaded multiple > inheritance, but it would be simple and explicit, with no magic. > > Eric > > I think either approach is fine as far as I'm concerned, though what Eric suggests is probably a bit simpler in terms of lines of code. Mike |
|
From: Nelle V. <nel...@gm...> - 2013-07-18 13:47:38
|
On 18 July 2013 15:27, Michael Droettboom <md...@st...> wrote: > On 07/17/2013 04:57 PM, Eric Firing wrote: > > On 2013/07/17 3:14 AM, Michael Droettboom wrote: > >> Yes. This is great work! > >> > >> Just to chime in (after having been away for most of this conversation) > --> > >> > >> I think we can do this reorganization now without introducing any > >> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class > >> methods. Refactoring how the pyplot wrapper is done can be done as a > >> separate project at a later time (or even in parallel if someone wants > >> to, since all of Nelle's work at the end of the day doesn't change the > >> Axes interface). > >> > >> My only other comment (and I mentioned this in PR #2213 as well) is that > >> having the short stub functions in the Axes class in addition to the > >> actual implementations elsewhere introduces a new > >> synchronization/maintenance problem between the two. Maybe it makes > >> sense to merely add the implementation functions to the Axes class > >> namespace dynamically. Magical, sure, but should have ultimately the > >> same result as far as introspection, autocompletion and other IPython > >> goodness is concerned. > >> > >> Mike > > Mike, > > > > One other option is to have the new private modules include mixin > > classes from which Axes would inherit methods. There would be a lot of > > mixins, and this would be an example of the dreaded multiple > > inheritance, but it would be simple and explicit, with no magic. > > > > Eric > > > > > I think either approach is fine as far as I'm concerned, though what > Eric suggests is probably a bit simpler in terms of lines of code. > I'm attempting an implementation of https://github.com/matplotlib/matplotlib/pull/2213 using mixins, to get my head around this idea. I'll keep you posted on the code. > > Mike > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X