Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc
Hi, I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put together plotornot during the SciPy sprints. I wouldn't advocate for linking to plotornot from matplotlib -- the idea is semi tongue-in-cheek, and meant to gauge to what extent there is consensus about plot styles. It's not set up to teach about rcParams, nor does it systematically explore all possible styles. The votes (>10K, last I checked) are saved, and eventually Adrian or I will look over the feedback and report back to you all. I haven't had time for that yet. I hope the name didn't *actually* offend anyone. At the risk of sounding unappreciative of MPL (which I love, and rely upon daily), I must admit I was disheartened after hearing the MPL devs at SciPy discuss styles and defaults. I understand that you don't want to change the default styles without a clearly better alternative. I also understand that, to some extent, style preferences are subjective. However, there seemed to be quite a bit of resistance to the idea that MPL defaults should change *at all.* Even if you ignore the subjective component of this (which I think is a mistake, since in my experience there is broad consensus that projects like ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling), there are some well-established visual principles that matplotlib violates. Some of my biggest pet peeves are: 1) The default 'axes.color_cycle' values should be equally visible, with similar luminance values. The current defaults (bgrcmyk) do not have this property -- c and y are harder to see, and thus carry less visual emphasis. A color table like the "Dark2" color brewer table ( http://learnr.files.wordpress.com/2009/04/colours-dark2.png, colorbrewer2.org) is more uniform, and carefully designed for visibility and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a smarter default? 2) The default 'jet' colormap for images has a lot of poor properties (which is even mentioned on the MPL docs at http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at ordering changes in hue (which is bigger -- purple or yellow?), and better at ordering changes in intensity or saturation. A colleague of mine designed a visualization tool for doctors, and found that the rainbow color table had a dramatic negative effect on the effectiveness of the tool (you can watch her TED talk about this at https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is especially frustrating, since it *cannot* be modified via rcParams 3) Some of the defaults violate Tufte principles like minimizing "chart junk." For example, the 'stepfilled' mode for hist is probably better than the default, which draws vertical lines between every bin. Those lines make the histogram noisier -- do they convey any extra information? Again, this can't be tweaked via rcParams. Sorry for being long-winded -- I just want to make the case that this is an important (and not *entirely* subjective) issue. If nothing else, it would be great to see some clear statement about where the MPL devs stand on this issue -- what criteria must be met to consider a change to the defaults? My apologies if such a document already exists somewhere! Cheers, Chris Beaumont On Sat, Jul 20, 2013 at 3:03 PM, < [email protected]> wrote: > Send Matplotlib-devel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Matplotlib-devel digest..." > > > Today's Topics: > >1. Re: Plot or Not: voting to create better matplotlibrc > (Eric Firing) >2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing) >3. Re: Plot or Not: voting to create better matplotlibrc > (Benjamin Root) >4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root) > > > -- > > Message: 1 > Date: Sat, 20 Jul 2013 08:20:11 -1000 > From: Eric Firing > Subject: Re: [matplotlib-devel] Plot or Not: voting to create better > matplotlibrc > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2013/07/20 4:18 AM, David P. Sanders wrote: >
Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc
'image.cmap' -- nice! Shows how much I know :)
I don't fully agree with Eric that changing the defaults should be treated
as an API break -- yes, it may irritate a minority of users, but their code
will still run. I'd flip around your argument for the role of rcParams and
customization: the majority user is probably someone who doesn't know much
about rcParams, or all the ways plots can be customized. *That* is the use
case to optimize, not the "legacy" users invested in the current style.
However, default tweaking need not be painful. As has been mentioned, a
first step would be an easier way to change a whole set of rcParams:
something like mpl.set_style('style-name'). As long as one style is
'classic', users can keep the current style for as long as they want. It's
a one line fix, and could even be rcParams-settable.
With such a framework, it would be possible for people to contribute new
styles that ship with MPL, and users could change styles without having to
find (and potentially merge) rcParams files from the web. Finally, people
could nominate that mature styles be made default (you could even assign
version numbers to track the default style as it evolves towards visual
awesomeness)
chris
On Sat, Jul 20, 2013 at 9:07 PM, Eric Firing wrote:
> On 2013/07/20 2:38 PM, David P. Sanders wrote:
> > And this is my problem with 'rc': it brings to mind an arcane config
> > file hidden away somewhere that has a terrible syntax and must not be
> > touched.
> >
> > As Chris and Adrian have emphasized, the point is that we *should* be
> > tweaking away at the parameters all the time.
> > I propose to rename as mpl_params=rcParams
> >
>
> Yes, mpl_params is more descriptive and easy to remember. rcParams is
> ugly, obscure, and archaic. It will have to remain available for a long
> time, but I don't object to changing standard usage to a nicer name.
> There might even be a better name than "mpl_params"--"settings" comes to
> mind, or maybe "style".
>
> As for parameter tweaking: the defaults shipped with mpl should be
> changed only rarely, but we should make it as easy as possible for users
> to customize plots, including coming up with good combinations of style
> parameters. In some cases it makes sense to do this via a matplotlibrc
> file, in other cases it is better to do the parameter setting explicitly
> at the top of a script.
>
> Regarding defaults, note that I said "rarely", not "never".
>
> The whole rc system could use a good review--maybe resulting in lots of
> changes, maybe not--so I welcome the attention you are directing to it.
>
> Eric
>
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc
I had the same question about opt-out vs opt-in. Personally, I vote for
opt-out. I would like to see each release of MPL have an associated style
(which may be the same as the last release, but maybe not). With Tony's
style PR, users that need constant styles would either put
`style.use('1.3')` in their script, or `style: 1.3` in an rcParams file.
This would then freeze the style FOR-EV-ER (sandlot voice). However, the
default would be `style: latest`, so that the default user benefits from
the community's effort into making the best possible set of defaults. Is
that sufficiently pain-free for people who want future proofing? Or do you
think styles must be opt-in (which, effectively, means that defaults cannot
change).
I'm not sure if I understand what you're getting at re:
approximately_emulate. I'm in favor of two modes for style loading -- some
kind of lazy version that only touches the options explicitly addressed in
the file, and an explicit version that defaults all other options to
something. Thus, explicit loading would guarantee that a style never
changes.
chris
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0rc5 tagged
Same with me. I had a stale pyparsing.pyc file in the MPL source directory (presumably from an old MPL version) whose version # was too old. When mpl tried to 'import pyparsing', it found that version, and raised an error. Of course, if I tried "import pyparsing; print pyparsing.__version__" from my home directory, python found a more recent pyparsing. So the error message was a little confusing. I only think this is going to effect people building from the Git source, who have the old pyparsing.pyc file. On Wed, Jul 24, 2013 at 10:45 AM, Benjamin Root wrote: > > > > On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom wrote: > >> On 07/23/2013 03:33 PM, Benjamin Root wrote: >> >> Just checked out rc5 from git and did an install, and ran into a >> pyparsing version check issue. >> >> >> What was the issue? Is it that you had 2.0.1 which rc5 still considers >> to be incompatible with Python 2? I'd like to know specifically what >> happened in case there's a deeper issue. >> >> >> > It claimed I didn't meet the minimum pyparsing version needed when I tried > importing matplotlib after installing from source. However, importing > pyparsing on its own yielded a version slightly above the minimum (I forget > the actual numbers). I had also just came from an build of an older > version of matplotlib. > > Ben > > > -- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Chris Beaumont Graduate Student Institute for Astronomy University of Hawaii at Manoa 2680 Woodlawn Drive Honolulu, HI 96822 www.ifa.hawaii.edu/~beaumont -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP19: Continuous integration virtual meeting
I'd like to sit in on this if I'm available. Please keep me posted Cheers, Chris -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Faceted plotting
Pandas has some nice tools to make faceted plots -- small multiples of plots where data is grouped by category ( http://pandas.pydata.org/pandas-docs/stable/rplot.html). However, I think there would be value in having this functionality built into matplotlib. Mainly: 1. Not every dataset lives in a dataframe 2. The pandas library mimics the ggplot interface, and some people would prefer an interface closer to matplotlib 3. Properly implemented, I think a matplotlib facet system would enable a wider variety of faceted plots than the pandas tools. I've taken a stab at this, and came up with an interface that I think has potential. This currently exists as a separate repository at https://github.com/ChrisBeaumont/mplfacet, and an example notebook at http://bit.ly/17u1JzP There two basic ways to use a facet object: Facet(key, data).method() will group one or more data arrays by key, and build a subplot for each group by calling method (which is any axes plot method). Alternatively, for item in Facet(key, data): x, y = item.data item.axes.scatter(x, y) sets up the subplots and groups the data for you, but gives you more freedom to populate each subplot however you like. Is there interest in building this into matplotlib? If so, I would like to polish it up and submit a PR. Cheers, Chris -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Faceted plotting
Hi Damon,
Thanks for your thoughts on how this should fit in with MPLs API. My $0.02:
What would feel more natural is if I could do the following:
> f = Facet(...)
> ax.facet(f, 'scatter')
>
Three things about this style bother me:
1. It seems too verbose ("facet" gets typed a lot -- 4 times if you call
the variable facet instead of f).
2. I don't love having to invoke methods like 'scatter' by naming them as a
string. It feels kludgy for some reason.
3. I think the axes plotting methods belong to a different category than a
facet. The former are "artist factories" that add artists like
lines/patches/etc to axes. A facet, on the other hand, is a higher-level
"axes factory" that creates multiple subplot axes objects. Making facet an
axes method seems out of place, since I think it's more natural to have a
separate axes for each subplot. What do you think?
Admittedly, functions like plot() are a total disaster, they take a
> plethora of different argument orders and types and try to conform to many
> calling signatures at once. Specifically, the way the data is passed to
> the plotting method varies wildly.
>
Good point. My implementation relies on a pretty general (but not universal
or formally documented) property of most plot functions: the first
arguments for each method are usually data arrays. This means that, in most
situations, Facet can extract the appropriate subset of the original data,
pass them as the first arguments to an axes method, and this will "do the
right thing". This works most of the time, but might be considered a hack.
The iterator interface is meant to address the cases where this doesn't
work (for example, calling Facet.imshow or Facet.streamplot doesn't work).
I think your Faceted plotting API supports exactly what I'm hoping to see
> matplotlib will move towards:
>
> class Facet(matplotlib.Plottable)
> def __init__(self, ...)
> ...
>
> f = Facet(...)
> ax.scatter(f)
>
This interface addresses my first two concerns above, but not the third --
I don't think that all facets should live in a single axes. I'm not sure
what you envision the Plottable interface looks like, but I imagine it
provides methods to extract data, so that you can plot things besides
arrays. In this case, I think a facet could *use* Plottables when building
subplots, but I'm not sure a facet *is* a plottable.
Tangential to the notion of Plottable objects: if there were a standard
protocol for passing data and style arguments to all plotting methods, it
would be easier to build robust, higher level axes factories. Facets are
one such factory, but there are others. For example (and not the prettiest,
I admit), see the map at
http://www.tableausoftware.com/public/gallery/new-jersey-test-score-analysis-visualization.
It's basically a faceted group of pie charts, that are positioned and sized
according to more data. The generalized description is something like:
atomic_plot + faceted_by(variable) + positioned_by(x, y) + sized_by(z)
Where atomic_plot is an axes plot method (e.g., ax.pie, but why not ax.bar
or any other single-variable plot?). You could imagine building a layered
API like this, and it would be easier if the interface for all atomic_plot
objects were compatible. Matplotlib was first built to win converts over
from matplotlib -- with a layered API, you can start converting the
ggplot/d3/bokeh/vega community :)
Cheers,
Chris
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Plot or Not Results Summary
Hi Everyone, I found some time to look at the votes from the "Plot or Not?" experiment Adrian Price-Whelan and I ran during SciPy last summer. You can take a look at my summary at http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-results/, or explore for yourself at http://plotornot.chrisbeaumont.org . Plot or Not was mostly a tongue-in-cheek idea, but there is nonetheless some interesting information about style preferences in these data. I'm happy to share the raw vote data if anyone is interested in digging further. Cheers, Chris Beaumont -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Meeting...?
I have another long-simmering feature request along these lines: if Matplotlib were to evolve a formal DOM-like figure structure like mentioned above, it would be cool if this structure retained more semantic information about the visualization itself. By this, I mean that many high-level commands like hist, scatter, etc. spawn a bunch of low level artists like rectangles and circles. After these methods exit, it's hard/impossible to introspect a Figure and diagnose that it, for example, is a histogram and not a bar chart. Retaining a better high-level description of a plot (which probably amounts to creating more compound artist types) would make it easier to build tools like mpld3 and other cool things that involve runtime editing or optimization of tree-like data structures. chris On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas wrote: > On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom wrote: > >> >> I hope all of the above makes sense... >> > > Definitely makes sense: what I've built-up in mpld3 is essentially > something that mimics this sort of visitor pattern, though it misses some > things because of the draw-time difficulties you mention. > I think a two-stage draw() would be a _very_ helpful restructure. > Currently, I'm forced to achieve this result by writing a png to a > throwaway byte-stream... >Jake > > >> >> Mike >> >> >> On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: >> >> Thanks - we'll make it happen at some point. >> >> Perhaps I can give the seed for a discussion: the stuff I've been doing >> with mpld3 is a lot of fun, but it's fundamentally limited by the fact that >> I have to dig around the internals of the figure object to find the >> relevant information to construct a plot representation. I may be able to >> do the same thing by creating a backend, but the problem is that the draw() >> methods of most objects call the renderer with no reference to whether the >> points lie in the data space or figure space: that is, paths and points are >> usually specified in figure/pixel coordinates or some transformed version >> thereof, which makes it near impossible to construct interactive >> representations absent Python kernel callbacks. >> >> What I'd love to see is some enhancement of the backend framework where >> there are some extra flags and information passed to the renderer: i.e. for >> each draw command, we need to know whether the drawn object should be >> linked to static figure coordinates or to dynamic axes/data coordinates. >> >> I've been in touch with Cyrille Rossant from the vispy team, Chris >> Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all >> of whom asked if there might be a way to use what I've done with mpld3 to >> enable matplotlib to export into their own front-end format. I didn't >> start mpld3 with that sort of extensibility in mind, but I'm starting to >> invest some time thinking about how to design that. >> >> With the current matplotlib package, I think there are two ways to >> accomplish it: one is to create a general backend-like interface based on >> the figure introspection that mpld3 currently uses. The artist elements in >> each figure contain enough information to be able to infer whether the >> elements should move & zoom with the axes or not. The problem is, a lot of >> elements (like legends, axes aspects, etc.) are not fully established until >> the draw() command is called, so there are a few ugly hacks required to >> make it happen. >> >> The other option is to use an even uglier hack, and wrap the current >> backend framework with an object that somehow links back into the figure >> and infers from the draw_*() commands whether the path/point/marker/etc. >> should be drawn in static figure coordinates or in dynamic axes >> coordinates. I've started a simple prototype backend translator which has a >> renderer class that uses ``inspect`` back-trace the stack and accomplish >> this: It's really ugly, and I'm not particularly proud about it, but I >> think it's the current best way to accomplish the desired behavior. >> >> Ugly hacks aside, I think all of this points to a general desire for a >> new type of backend-like hook that can export dynamic plot elements in data >> coordinates, and static plot elements in figure coordinates. An >> enhancement in that direction could pave the way for a lot of interesting >> interactive front-ends to matplotlib figures. >> >> Anyway - if any of you have suggestions or responses to this,
Re: [matplotlib-devel] OSX framework detection
Hi Derek, > the framework. Though, if I understand correctly, Anaconda provides a > framework version of the interpreter > pythonw and a non-frameworked python? This is right -- the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries are equivalent under most other python installs. E.g. the mac system python manpage reads: To support multiple versions, the programs named python and pythonw now just select the real version of Python to run, depending on various set- tings. (As of Python 2.5, python and pythonw are interchangeable; both execute Python in the context of an application bundle, which means they have access to the Graphical User Interface; thus both can, when properly programmed, display windows, dialogs, etc.) So people don't usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash). This definitely seems like Anaconda's problem rather than matplotlib's (it affects any program that tries to import Qt, e.g.) chris -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
> > to under OS X 10.9 with the Fink Python installation (which is not >> built as a framework, and unfortunately unlikely >> > to change in foreseeable time). I.e. the only obvious problem is the >> lack of control by the window manager. >> > Overall I still find it to perform better than any of the alternative >> backends. But having switched to PyQT4 as the >> > default backend due to the above Fink troubles, I did notice some >> oddities under Mavericks. I have no idea if they >> > are related to the problems Eric had originally reported, but they are >> clearly Mavericks-specific: >> > >> > When using MPL with ipython --pylab and the Quartz version of PyQT4, >> the interpreter seems to be slow down >> >> > extremely after running for a little while. Weirdly this is not >> connected to any graphics display and in fact happens >> > even without any plotting window opened, i.e. the ipython shell just >> randomly becomes completely unresponsive >> > and hangs for several seconds on simple tasks like typing or navigating >> through history. The plotting itself actually >> > does not appear to perform any worse than it used to under Mountain >> Lion. >> > None of this seems to occur with the X11 variant of PyQT4. >> > When launching ipython without the --pylab flag and loading MPL later >> (e.g. with 'import matplotlib' in the ipython >> >> > profile), none of these stalls or hangups occur, but plots sometimes >> seem not to refresh properly even with a >> > plt.draw() and one has to manually resize the plot window to force >> redrawing of the figure. >> > This might be primarily a PyQT4 or Ipython issue, but obviously it is >> somehow connected to the pylab mode of Ipython. >> > >> > Cheers, >> > Derek >> > >> > -- >> > Anaconda Community Support Group Brought to you by Continuum Analytics >> > --- >> > You received this message because you are subscribed to the Google >> Groups "Anaconda - Public" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at >> http://groups.google.com/a/continuum.io/group/anaconda/. >> > > > > -- > > 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 > > [email protected] > > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- * Chris Beaumont Senior Software Engineer Harvard Center for Astrophysics 60 Garden Street, MS 42 Cambridge, MA 02138 chrisbeaumont.org * -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
