I'm very interested in putting together a document that
> would be incorporated into the user's manual that would
> describe the abstractions used by matplotlib. I think that
> this would help me to understand it better, and would also
> be useful to the community. Does anything like this
> currently exist?
The best starting point for this is the "Leftwich tutorial"
This is written in structured text. If you are interested in
extending this (and a lot can be done here) the best place to start
IMO is to get this into the proper format for the matplotlib wiki and
uploaded there, so we can all make contributions to it. There may be
minor differences in the structured text format that need to be
> To answer Eric's most recent posting:
> 1. I think that scientific notation should not be the
> default, unless numbers exceed 1E+7.
I agree with this -- scientific notation kicks in too soon IMO. I
think an rc setting would be fine. I am not adverse to more rc
settings personally. I haven't seen too many problems arising from
having a lot of rc settings.
> 2. It would be nice if there was an easy way to get commas
> into numbers. (This is forever a problem; I wish that the
> original C folks had thought to put commas into their
> original printf formatting. I have a nice python commas
> function if you want it, although you can probably create
> one that is more efficient.)
This would be a great custom formatter -- see
http://matplotlib.sf.net/matplotlib.ticker.html for details on the
Formatter. Please contribute one if you can.
> 3. If I was going to make a major change to the API at
> this point, it would be to make it so that you don't have
> a class/function/ identifier called "axes" and another one
> called "axis." I frequently get confused between these two
> words; I imagine that non-native English speakers get
> confused even more frequently. Irregular noun plurals in
> English are confusing, and it probably isn't necessary to
> use both. One approach would be to never allow "axis," to
> only allow "xaxis" and "yaxis" and perhaps something
> (either_axis?) for the abstract super-class, but this may
> be a bigger change than you wish to consider at the
> present time.
Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.
> Ah, the matplotlibrc file. It seems that you are trying
> to do too much with this file. Is the point of the file
> to have default graphing behavior, or to have site-wide
> configuration information? You may wish to split the file
> into two parts --- a config part and a graphing
> preferences part --- because it seems that sometimes
> people wish to change one without changing the other. Or
> you may want to have explicit inheritance --- like an
> "-include" feature so that a local file can just shadow
> some variables and then include the master file. I
> understand that this can be done with a few lines of
> python at the top of a program. Of course, given that
> option, you may wish to do away with the local files
> entirely. I'm not sure.
The rc file is meant to support local customization, and directory
specific files are meant to support project specific customizations.
The idea here is: you may want a general configuration for most plots,
interactive plotting, etc, but you may want something entirely
different for a directory which contains a figure for a journal
article: PS backend, latex text, larger fontsizes, thicker lines...
The current implementation certainly has some limitations: we'd prefer
the file to be python rather than our own yet-another-rc-file-markup
and yes, we'd like to support includes and overrides with a basic
inheritance and namespace support, which we would get for free by
simply making the rc file python. This is an idea waiting to be
implemented. We'd probably borrow some work from recent changes to
ipython which were implemented to solve some of the same problems.
> Have the matplotlib developers put together a roadmap of
> their directions that they want to take this project?
though it is not updated as often as it should be and is not entirely current.