Menu
▾
▴
matplotlib-devel
|
From: Michael D. <md...@st...> - 2013-10-24 13:43:52
|
Just a reminder, we are having a general matplotlib development hangout
today. Everyone that responded to the Doodle poll from a few weeks ago
will get an invite, along with Matthew Terry and Matthew Brett if they
can make it to discuss their work with testing and builds.
We have a few extra spots, so let me know if you'd like an invite (first
come, first served).
I'll post a public URL to watch along once it begins as well.
Mike
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com
|
|
From: Todd <tod...@gm...> - 2013-10-24 15:27:09
|
Was anyone looking at the questions? I posted a bunch of questions but nobody seemed to notice them. On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom <md...@st...> wrote: > Just a reminder, we are having a general matplotlib development hangout > today. Everyone that responded to the Doodle poll from a few weeks ago > will get an invite, along with Matthew Terry and Matthew Brett if they > can make it to discuss their work with testing and builds. > > We have a few extra spots, so let me know if you'd like an invite (first > come, first served). > > I'll post a public URL to watch along once it begins as well. > > Mike > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Michael D. <md...@st...> - 2013-10-24 15:32:43
|
Here are the notes with action items from the meeting: https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing Sorry about not seeing questions posted from non-participants. I'll try to work out that kink for next time. Mike On 10/24/2013 09:41 AM, Michael Droettboom wrote: > Just a reminder, we are having a general matplotlib development hangout > today. Everyone that responded to the Doodle poll from a few weeks ago > will get an invite, along with Matthew Terry and Matthew Brett if they > can make it to discuss their work with testing and builds. > > We have a few extra spots, so let me know if you'd like an invite (first > come, first served). > > I'll post a public URL to watch along once it begins as well. > > Mike > -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Nelle V. <nel...@gm...> - 2013-10-24 15:56:59
|
Hi, For the CI stuff, I think it would be worth discussing this with the Enthought guys, specifically Didrik Pinte and David Cournapeau. >From what I understood, they are developping some stuff to automatically build canopy from projects hosted on github. Hence, they have to run all the tests, on different plateforms, and they are OK with chatting with some of us. Cheers, N On 24 October 2013 17:29, Michael Droettboom <md...@st...> wrote: > Here are the notes with action items from the meeting: > > https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing > > Sorry about not seeing questions posted from non-participants. I'll try > to work out that kink for next time. > > Mike > > On 10/24/2013 09:41 AM, Michael Droettboom wrote: >> Just a reminder, we are having a general matplotlib development hangout >> today. Everyone that responded to the Doodle poll from a few weeks ago >> will get an invite, along with Matthew Terry and Matthew Brett if they >> can make it to discuss their work with testing and builds. >> >> We have a few extra spots, so let me know if you'd like an invite (first >> come, first served). >> >> I'll post a public URL to watch along once it begins as well. >> >> Mike >> > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Chris B. <chr...@no...> - 2013-10-24 18:40:18
|
On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> wrote: > Here are the notes with action items from the meeting: thanks for posting that. I see: pylab - should it stay or should it go? Comment from the peanut gallery: Go. But beyond that, matplotlib.pyplot is a big mess of both the matlab-style state-machine current figure, current axis stuff, and what you need to do (at least reasonably on the command line) OO interface. This makes it really hard to teach to newbies -- I just did this last night, and made a point to use tutorials that emphasize the OO interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm sure others that helped put the materials together that I stole from...). However, there were still a number of examples in there that just called "plot()" or whatever, and even if there were not, the namespace is really cluttered with stuff! Anyone like the idea of an matplotlib.ooplot namespace that would have just what you need to use the oo style? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Todd <tod...@gm...> - 2013-10-25 19:50:24
|
On Oct 24, 2013 8:40 PM, "Chris Barker" <chr...@no...> wrote: > > On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> wrote: > > Here are the notes with action items from the meeting: > > thanks for posting that. I see: > > pylab - should it stay or should it go? > > Comment from the peanut gallery: > > Go. I agree, but that leads to another question: go where? Some of the stuff there is clearly redundant and should be removed entirely. Others I think are functionality that should be merged into numpy, although whether they would agree I don't know. Others are useful but I don't know exactly where they could end up. I think we need to go through on a case-by-case basis and figure out what to do with each class and function. I think it would probably be good to do something similar with cbook. Both are dumping grounds for largely unrelated functions. At the very least they should be organized into modules by their purpose, but I do think some should be dropped or upstreamed. |
|
From: Daniele N. <da...@gr...> - 2013-10-24 19:03:30
|
On 24/10/2013 20:39, Chris Barker wrote: > On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> wrote: >> Here are the notes with action items from the meeting: > > thanks for posting that. I see: > > pylab - should it stay or should it go? > > Comment from the peanut gallery: > > Go. > > But beyond that, matplotlib.pyplot is a big mess of both the > matlab-style state-machine current figure, current axis stuff, and > what you need to do (at least reasonably on the command line) OO > interface. > > This makes it really hard to teach to newbies -- I just did this last > night, and made a point to use tutorials that emphasize the OO > interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm > sure others that helped put the materials together that I stole > from...). However, there were still a number of examples in there that > just called "plot()" or whatever, and even if there were not, the > namespace is really cluttered with stuff! > > Anyone like the idea of an matplotlib.ooplot namespace that would have > just what you need to use the oo style? Hello, I agree that the matlab like API should be at least discouraged, however I think there are some shortcomings both in the documentation and examples and in the object oriented API and functions exposed through the pyplot namespace that make switching more cumbersome that it has to bee. One thing I dislike is, for example, the add_subplot() method: f = plt.figure() a = f.add_subplot(111) a.plot(x, y) it feels completely out of place (why I need to add a subplot if the only thing I want to do is to create a figure with a single plot in it?) and kind of magic (what is the number 111?). The API is also very old fashion python (getter and setter methods for example) and many methods try to emulate too much of the bad API design of matlab (doing completely different things depending on the kind and number of parameters). I believe it would be possible to come up with a more modern and lean API that would be easier and nicer to use. If we have to deprecate the matlab style API, maybe it would be worth to replace it with something substantially better. PS: Chris, would you mind sharing the material you put together and links to material from which you stole from? Thanks! Cheers, Daniele |
|
From: Chris B. <chr...@no...> - 2013-10-24 19:47:56
|
On Thu, Oct 24, 2013 at 12:03 PM, Daniele Nicolodi <da...@gr...> wrote: > PS: Chris, would you mind sharing the material you put together and > links to material from which you stole from? Thanks! I honestly don't think my stuff is any better than the originals: I like these: Ben Root's Scipy Tutorial -- really nice, Ben! https://github.com/WeatherGod/AnatomyOfMatplotlib >From the software carpentry site: https://github.com/swcarpentry/bc/tree/gh-pages/lessons/thw-matplotlib (apparently originally from Katy and Antony) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Daniele N. <da...@gr...> - 2013-10-25 12:45:08
|
On 24/10/2013 21:26, Paul Ivanov wrote: > One quick reply: > > Daniele Nicolodi, on 2013-10-24 21:03, wrote: >> One thing I dislike is, for example, the add_subplot() method: >> >> f = plt.figure() >> a = f.add_subplot(111) >> a.plot(x, y) >> >> it feels completely out of place (why I need to add a subplot if the >> only thing I want to do is to create a figure with a single plot in it?) >> and kind of magic (what is the number 111?). > > f, a = plt.subplots() > a.plot(x, y) That's better, however to create _sub_ plots to have a single plot into a figure still feels weird, also I would expect it to be a method of the Figure class and not a top level function. Furthermore, most documentation refers to add_subplot() and not subplots() which has a more understandable function signature. In principle I think the current API violates the "There should be one-- and preferably only one --obvious way to do it" rule here, and elsewhere :-) I feel the way forward should be to create a cleaner API and map the current one through a compatibility layer to that. Cheers, Daniele |
|
From: Benjamin R. <ben...@ou...> - 2013-10-25 13:34:45
|
Daniele, On Fri, Oct 25, 2013 at 8:45 AM, Daniele Nicolodi <da...@gr...>wrote: > On 24/10/2013 21:26, Paul Ivanov wrote: > > One quick reply: > > > > Daniele Nicolodi, on 2013-10-24 21:03, wrote: > >> One thing I dislike is, for example, the add_subplot() method: > >> > >> f = plt.figure() > >> a = f.add_subplot(111) > >> a.plot(x, y) > >> > >> it feels completely out of place (why I need to add a subplot if the > >> only thing I want to do is to create a figure with a single plot in it?) > >> and kind of magic (what is the number 111?). > > > > f, a = plt.subplots() > > a.plot(x, y) > > That's better, however to create _sub_ plots to have a single plot into > a figure still feels weird, It doesn't feel weird. It feels generalized. It is the same way to add any number of plots, regardless if it is just one, or twenty. If you don't want to do it that way, you can just simply do: fig = plt.figure() ax = fig.gca() # "get current axes" automatically creates an axes if one doesn't exist already You also have http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_axes > also I would expect it to be a method of the > Figure class and not a top level function. It does: http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot This is *the* function that does axes creation for a figure, whether it is one, or many. > Furthermore, most > documentation refers to add_subplot() and not subplots() which has a > more understandable function signature. > > subplots() is a recent addition. We are in the process of updating our documentation. But add_subplot() is not going away because it works just fine, and it is very familiar to users of Matlab and Octave. > In principle I think the current API violates the "There should be one-- > and preferably only one --obvious way to do it" rule here, and elsewhere > :-) > > I feel the way forward should be to create a cleaner API and map the > current one through a compatibility layer to that. > > This has already been done. We have the GridSpec API that everything else maps to, for compatibility. But most people still like add_subplot() and subplots() for some odd reason... I think the primary issue is one of documentation, and we are currently in the process of upgrading that. We always welcome contributions to that effort! Cheers! Ben Root |
|
From: Chris B. <chr...@no...> - 2013-10-25 22:29:18
|
On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root <ben...@ou...> wrote: > It doesn't feel weird. It feels generalized. > or both ;-) It is the same way to add any number of plots, regardless if it is just > one, or twenty. If you don't want to do it that way, you can just simply do: > > fig = plt.figure() > ax = fig.gca() # "get current axes" automatically creates an axes if one > rally ugly -- the whole point here is to get away from the concept of a "current" anything -- I'm actually surprised that that's a figure method at all... It does: http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot > This is *the* function that does axes creation for a figure, whether it is > one, or many. > > subplots() is a recent addition. > And a nice one -- I've been wanting that for years! (and I first discovered it in your tutorial, Ben!) The trick has always been that plot() actually creates (If not re-using) three objects you might want to work with: figure, axes, and line objects, so an oo interface that lets you do that with one call is tricky -- I think this is a nice compromise. We are in the process of updating our documentation. But add_subplot() is > not going away because it works just fine, and it is very familiar to users > of Matlab and Octave. > I've lost track a bit if there is support for a new OO-only API (namespace), in which case, maybe some of this could be cleaned up as well. I'd kind of like to see a fig.subplots() that has the same API as plt.subplots(), for symmetry's sake, and because add_subplot() has a kind of crufty API. Except it wouldn't return the figure instance (though it could). -Chris > > >> In principle I think the current API violates the "There should be one-- >> and preferably only one --obvious way to do it" rule here, and elsewhere >> :-) >> >> > I feel the way forward should be to create a cleaner API and map the >> current one through a compatibility layer to that. >> >> > This has already been done. We have the GridSpec API that everything else > maps to, for compatibility. But most people still like add_subplot() and > subplots() for some odd reason... I think the primary issue is one of > documentation, and we are currently in the process of upgrading that. We > always welcome contributions to that effort! > > Cheers! > Ben Root > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Daniele N. <da...@gr...> - 2013-10-25 15:26:21
|
On 25/10/2013 15:34, Benjamin Root wrote: > This has already been done. We have the GridSpec API that everything > else maps to, for compatibility. But most people still like > add_subplot() and subplots() for some odd reason... I think the primary > issue is one of documentation, and we are currently in the process of > upgrading that. We always welcome contributions to that effort! Hello Benjamin, thanks for your comments. I'm aware of the solutions you propose, but I maintain that the status quo is confusing for new users. The fact that there are multiple ways of doing the same thing, through apparently unrelated interfaces makes the API more difficult to learn and less discoverable that it needs to be. This is probably a conseqence of the organic growth of the library with time. I agree that the primary issue is the documentation, but at the root of that I also feel there is the lack of well established best practices for the use of Matplotlib. For example you write that people still like add_subplot() and subplots() for odd reasons, which are the methods others in the lists pointed to. What would be the proper API to use in your opinion? I believe convergence on best practices is paramount to the update of the documentation. I also don't really buy the argument that it is desirable to keep and promote APIs that try to emulate the Matlab interface. Matplotlib is different enough to make a 1:1 translation difficult and the Matlab design is anyhow broken, IMHO. Best, Daniele PS: with a new job also came the possibility to finally drop Matlab and embrace Python as the main data analysis tool. This means that I can dedicate some (at the moment very few) spare cycles to contribute to Matplotlib. I would be happy to do so! |
|
From: Thomas A C. <tca...@uc...> - 2013-10-25 17:21:08
|
There needs to be layers to the interface. At the bottom there is super general stuff that will cover (we hope) 100% of use cases. However, the cost is a very verbose interface with lots of knobs. To cope with this there are higher level function which can deal with 90% of the use cases and do so by hiding some of the knobs (compare making a 3x3 grid `subplots(3, 3)` with using `GridSpec` to figuring out where the axes edges should go and using `add_subplot([t, l, w, h])` ). I want to make an analogy to projecting from a higher dimensional parameter space to a lower one. The 'proper' api to use is the simplest one that achieves your goal. If you just need a grid of evenly spaced equal size axes use `subplots`, if you need a grid but with some axes that span columns/rows use `GridSpec`, if you need 5 axes that partially overlap in the shape of your school logo, use `add_subplot`. The point of the high-level APIs is to be easy to use. If that means matching the MATLAB api to make it easier for people to switch, then fine. I am sympathetic to the notion that the state-machine interface is confusing (because it maintains hidden state), but it is in fact very convenient. On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <da...@gr...>wrote: > On 25/10/2013 15:34, Benjamin Root wrote: > > > This has already been done. We have the GridSpec API that everything > > else maps to, for compatibility. But most people still like > > add_subplot() and subplots() for some odd reason... I think the primary > > issue is one of documentation, and we are currently in the process of > > upgrading that. We always welcome contributions to that effort! > > Hello Benjamin, > > thanks for your comments. I'm aware of the solutions you propose, but I > maintain that the status quo is confusing for new users. > > The fact that there are multiple ways of doing the same thing, through > apparently unrelated interfaces makes the API more difficult to learn > and less discoverable that it needs to be. This is probably a > conseqence of the organic growth of the library with time. > > I agree that the primary issue is the documentation, but at the root of > that I also feel there is the lack of well established best practices > for the use of Matplotlib. For example you write that people still like > add_subplot() and subplots() for odd reasons, which are the methods > others in the lists pointed to. What would be the proper API to use in > your opinion? I believe convergence on best practices is paramount to > the update of the documentation. > > I also don't really buy the argument that it is desirable to keep and > promote APIs that try to emulate the Matlab interface. Matplotlib is > different enough to make a 1:1 translation difficult and the Matlab > design is anyhow broken, IMHO. > > Best, > Daniele > > PS: with a new job also came the possibility to finally drop Matlab and > embrace Python as the main data analysis tool. This means that I can > dedicate some (at the moment very few) spare cycles to contribute to > Matplotlib. I would be happy to do so! > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&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: Todd <tod...@gm...> - 2013-10-25 22:32:55
|
I think one thing that contributes a lot to the API issues is the inconsistency between pyplot API and the OO API. There isn't any reason the APIs need to be so different. To continue with this example, pyplot.subplot and Figure.add_subplot do basically the same thing, but they have different names. In practice pyplot.subplot essentially acts as a wrapper for gcf().add_subplot, but it isn't exactly the same internally, it has some checks that are not present in Figure.add_subplot but really should be. On the other hand, pyplot.subplots doesn't exist at all in Figure, all the functionality is implemented in pyplot. So the idea would be to have essentially all of the pyplot functions just be wrappers for methods from other classes, using the same name and same call signature (minus "self"). All of the actual functionality would be implemented in the methods, the pyplot functions should not have any logic or tests. So pyplot.subplot would be just be a wrapper for gcf().subplot, pyplot.subplots would just be a wrapper for gcf().subplots, while pyplot.plot would just be a wrapper for gcf().gca().plot. This will make it easy to transition between the two, learning to use the OO interface would just involve learning what object the pyplot function is targeting (this should be in the pyplot function docstring). On Fri, Oct 25, 2013 at 7:21 PM, Thomas A Caswell <tca...@uc...>wrote: > There needs to be layers to the interface. At the bottom there is super > general stuff that will cover (we hope) 100% of use cases. However, the > cost is a very verbose interface with lots of knobs. To cope with this > there are higher level function which can deal with 90% of the use cases > and do so by hiding some of the knobs (compare making a 3x3 grid > `subplots(3, 3)` with using `GridSpec` to figuring out where the axes > edges should go and using `add_subplot([t, l, w, h])` ). I want to make an > analogy to projecting from a higher dimensional parameter space to a lower > one. > > The 'proper' api to use is the simplest one that achieves your goal. If > you just need a grid of evenly spaced equal size axes use `subplots`, if > you need a grid but with some axes that span columns/rows use `GridSpec`, > if you need 5 axes that partially overlap in the shape of your school logo, > use `add_subplot`. > > The point of the high-level APIs is to be easy to use. If that means > matching the MATLAB api to make it easier for people to switch, then fine. > I am sympathetic to the notion that the state-machine interface is > confusing (because it maintains hidden state), but it is in fact very > convenient. > > > On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <da...@gr...>wrote: > >> On 25/10/2013 15:34, Benjamin Root wrote: >> >> > This has already been done. We have the GridSpec API that everything >> > else maps to, for compatibility. But most people still like >> > add_subplot() and subplots() for some odd reason... I think the primary >> > issue is one of documentation, and we are currently in the process of >> > upgrading that. We always welcome contributions to that effort! >> >> Hello Benjamin, >> >> thanks for your comments. I'm aware of the solutions you propose, but I >> maintain that the status quo is confusing for new users. >> >> The fact that there are multiple ways of doing the same thing, through >> apparently unrelated interfaces makes the API more difficult to learn >> and less discoverable that it needs to be. This is probably a >> conseqence of the organic growth of the library with time. >> >> I agree that the primary issue is the documentation, but at the root of >> that I also feel there is the lack of well established best practices >> for the use of Matplotlib. For example you write that people still like >> add_subplot() and subplots() for odd reasons, which are the methods >> others in the lists pointed to. What would be the proper API to use in >> your opinion? I believe convergence on best practices is paramount to >> the update of the documentation. >> >> I also don't really buy the argument that it is desirable to keep and >> promote APIs that try to emulate the Matlab interface. Matplotlib is >> different enough to make a 1:1 translation difficult and the Matlab >> design is anyhow broken, IMHO. >> >> Best, >> Daniele >> >> PS: with a new job also came the possibility to finally drop Matlab and >> embrace Python as the main data analysis tool. This means that I can >> dedicate some (at the moment very few) spare cycles to contribute to >> Matplotlib. I would be happy to do so! >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&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 > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Chris B. <chr...@no...> - 2013-10-31 15:49:43
|
On Fri, Oct 25, 2013 at 3:32 PM, Todd <tod...@gm...> wrote: > I think one thing that contributes a lot to the API issues is the > inconsistency between pyplot API and the OO API. There isn't any reason > the APIs need to be so different. > indeed. I hadn't even realized how different they were. > So the idea would be to have essentially all of the pyplot functions just > be wrappers for methods from other classes, using the same name and same > call signature (minus "self"). All of the actual functionality would be > implemented in the methods, the pyplot functions should not have any logic > or tests. > + inf However, doing this with full backward compatibility could be a real challenge... This will make it easy to transition between the two, learning to use the > OO interface would just involve learning what object the pyplot function is > targeting (this should be in the pyplot function docstring). > That would help, though a namespace without any non-OO stuff would be still be good, and, of course, docs and tutorials. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Todd <tod...@gm...> - 2013-10-24 16:00:33
|
Here are the questions I asked during the hangouts session (paraphrased): ------------------------------------------------------------- Regarding continuous integration: Has looked into OBS? (open build server, https://build.opensuse.org/) It can be installed on a local machine or server, supports automatically creating and deleting fresh images with each build, and supposedly works with osX as well as Linux although I haven't tested it (it does need a Mac OsX VM). ------------------------------------------------------------- Regarding bug handling: It might be possible to do something with this with Google Code-in ( https://developers.google.com/open-source/gci/), although I am not 100% sure this would be acceptable there. Another possibility would be to allow volunteer triagers who may not be developers but can at least handle basic stuff like finding duplicates and following up with the reporters of old bugs. ------------------------------------------------------------- Regarding embedding: Perhaps there could be a generic "figure" widget for each backend. The widget would automatically handle all the backend-specific stuff necessary to create a figure object and display it in the widget (including resizing and such). It would provide access to the low-level backend-specific parts to make it possible to subclass it or change the details of how it works. The figure windows would have this widget as their central widget, and would probably access it using these low-level components. However, for basic usage each widget would also have a "figure" attribute, which would contain a single generic figure object. Basic users who just want to embed a regular plot could access that figure object and use it in the normal way. These could probably all be accessed from a single module, although they probably would all live in their own backend-specific modules. It wouldn't allow people to use pyplot, but if this was the documented way to do embedding and the documentation made it clear you needed to use the OO interface when embedding I think it would greatly reduce the amount of trouble people have. |
|
From: Paul I. <pi...@be...> - 2013-10-24 19:27:03
|
One quick reply:
Daniele Nicolodi, on 2013-10-24 21:03, wrote:
> One thing I dislike is, for example, the add_subplot() method:
>
> f = plt.figure()
> a = f.add_subplot(111)
> a.plot(x, y)
>
> it feels completely out of place (why I need to add a subplot if the
> only thing I want to do is to create a figure with a single plot in it?)
> and kind of magic (what is the number 111?).
f, a = plt.subplots()
a.plot(x, y)
that's the way to go there. And if you need to make a regular
grid of subplots, you can pass it the number of rows and number
of columns, and get a 2D array of subplots out for the second
argument.
f, axes = plt.subplots(2,3)
axes[0,2].plot(range(10))
axes[1,1].plot(-np.arange(10))
f.canvas.draw()
best,
--
_
/ \
A* \^ -
,./ _.`\\ / \
/ ,--.S \/ \
/ `"~,_ \ \
__o ?
_ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org
|
|
From: Paul I. <pi...@be...> - 2013-10-24 19:30:21
|
Michael Droettboom, on 2013-10-24 09:41, wrote: > I'll post a public URL to watch along once it begins as well. Here's the youtube video link (which I got from Mike's G+): https://www.youtube.com/watch?feature=player_embedded&v=hWA6dMiSUiU best, -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org |
|
From: Todd <tod...@gm...> - 2013-10-25 22:42:28
|
I think another problem is having pyplot and axes as dumping grounds for all plot types. This probably made sense back when there were only a few types of plots, but now there is a massive number of them. They all end up in one large class with one large documentation page, making it very hard to find exactly what you are looking for. In order to make the plots really useful, I definitely think a reorganization is in order. I think matplotlib needs an general module, perhaps "plots", that contains sub-modules for different types of plots (like bar plots), and those sub-modules contain functions, all of which have an axes object as their first argument. These could still be attached to axes as methods at least as a transition, but it would leave the axes class with methods that really have to do with axes, and not plotting per se. This would also make it possible to put code shared between plot types with those plot types in their module. On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chr...@no...> wrote: > On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> > wrote: > > Here are the notes with action items from the meeting: > > thanks for posting that. I see: > > pylab - should it stay or should it go? > > Comment from the peanut gallery: > > Go. > > But beyond that, matplotlib.pyplot is a big mess of both the > matlab-style state-machine current figure, current axis stuff, and > what you need to do (at least reasonably on the command line) OO > interface. > > This makes it really hard to teach to newbies -- I just did this last > night, and made a point to use tutorials that emphasize the OO > interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm > sure others that helped put the materials together that I stole > from...). However, there were still a number of examples in there that > just called "plot()" or whatever, and even if there were not, the > namespace is really cluttered with stuff! > > Anyone like the idea of an matplotlib.ooplot namespace that would have > just what you need to use the oo style? > > -Chris > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chr...@no... > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Michael D. <md...@st...> - 2013-10-30 14:42:36
|
On 10/25/2013 06:42 PM, Todd wrote: > I think another problem is having pyplot and axes as dumping grounds > for all plot types. This probably made sense back when there were > only a few types of plots, but now there is a massive number of them. > They all end up in one large class with one large documentation page, > making it very hard to find exactly what you are looking for. > > In order to make the plots really useful, I definitely think a > reorganization is in order. I think matplotlib needs an general > module, perhaps "plots", that contains sub-modules for different types > of plots (like bar plots), and those sub-modules contain functions, > all of which have an axes object as their first argument. These could > still be attached to axes as methods at least as a transition, but it > would leave the axes class with methods that really have to do with > axes, and not plotting per se. This would also make it possible to > put code shared between plot types with those plot types in their module. Nelle Varaquoax has already started this work on master. The separation of core axes functionality from plotting functionality has already been done, and the next steps involve organizing the plotting functionality further. This is a gargantuan task, and I'm sure Nelle would appreciate some assistance if you wanted to coordinate with her. Mike > > On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker <chr...@no... > <mailto:chr...@no...>> wrote: > > On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom > <md...@st... <mailto:md...@st...>> wrote: > > Here are the notes with action items from the meeting: > > thanks for posting that. I see: > > pylab - should it stay or should it go? > > Comment from the peanut gallery: > > Go. > > But beyond that, matplotlib.pyplot is a big mess of both the > matlab-style state-machine current figure, current axis stuff, and > what you need to do (at least reasonably on the command line) OO > interface. > > This makes it really hard to teach to newbies -- I just did this last > night, and made a point to use tutorials that emphasize the OO > interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm > sure others that helped put the materials together that I stole > from...). However, there were still a number of examples in there that > just called "plot()" or whatever, and even if there were not, the > namespace is really cluttered with stuff! > > Anyone like the idea of an matplotlib.ooplot namespace that would have > just what you need to use the oo style? > > -Chris > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 <tel:%28206%29%20526-6959> voice > 7600 Sand Point Way NE (206) 526-6329 <tel:%28206%29%20526-6329> fax > Seattle, WA 98115 (206) 526-6317 <tel:%28206%29%20526-6317> > main reception > > Chr...@no... <mailto:Chr...@no...> > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > the most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
×
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