matplotlib-devel Mailing List for matplotlib (Page 2)

On Thursday 26 July 2007 11:40:23 am Fernando Perez wrote:
> On 7/26/07, Darren Dale <dd...@co...> wrote:
> > On Thursday 26 July 2007 10:30:34 am Ted Drain wrote:
> > > Why do you need an api file at all? Why not have config be a python
> > > package and let config/__init__.py take care of importing
> > > everything?
[...]
> I don't remember the exact details, but we started using the api.py
> approach instead of __init__ on Enthought's lead
[...] 
> You may want to inquire with them for the details
I did ask at enthought-dev, and they said it was primarily due to circular 
dependencies. The use of __init__ is already causing us some headaches in 
mpl, so I decided to stick with api.py, leaving __init__ empty.
I just uploaded my work to matplotlib svn. The idea is that matplotlib would 
import the rcParams (and eventually mplConfig) from config/api, but for just 
think of config/ as a sandbox. The new config system is turned on by default 
in api.py by setting 
USE_NEW_CONFIG = True
If it is True, you can run configtest.py in IPython, which will import the 
traited mplConfig object and rcParams, a thin wrapper to mplConfig. 
configtest will change rcParams['backend'] to Cairo, validate that the change 
occured in mplConfig, and will then try to change the backend to something 
nonsensical and should throw an error.
For now, validation in mplConfig is very similar to validation in the old 
system. I have not taken advantage of the more advanced capabilities of 
traits, like shadow attributes and so forth. For now I just wanted to get 
something that should work with existing matplotlib. 
The first time the traited config module mplconfig is loaded, it checks your 
config_dir (the cwd and then probably ~/.matplotlib) for a matplotlib.conf 
file. If it does not exist, it creates one, loads your old matplotlibrc, 
updates mplConfig based on your matplotlibrc, saves any non-default settings 
to the new matplotlib.conf. If the file does exist, it updates mplConfig 
accordingly.
The config/matpltolib.conf.default file was auto-generated (comments and all, 
thanks to Fernandos wizardry).
Darren

On Friday 27 July 2007 08:38:49 am Michael Droettboom wrote:
> If we go with another delimiter, there are others in TeX to choose
> from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both
> of these are less likely to be legitimate literals. While display math
> normally implies that the math is placed on a separate line (not inline
> with the text), it's not far from what matplotlib does, since it follows
> the display math layout patterns.
I think $$ might be a bad idea, that has a very specific meaning in TeX, which 
is different than $. Like wise, \[ means display math while \( means inline 
math. \( ... \) is considered to be fragile, while $ ... $ is robust, but 
maybe \( \) would be a good solution. Then you could even switch between 
mathtext and usetex, and the usetex code wouldnt have to go through strings 
trying to substitute latex mathmode indicators for mpl indicators.
Darren

On Fri, Jul 27, 2007 at 08:52:27AM -0400, Michael Droettboom wrote:
> Using this "mathtext=True" option (as opposed to using a delimiter that 
> TeX doesn't understand) or something else entirely, would certainly make 
> it easier to make usetex vs. not usetex more consistent.
I think so to.
> More broadly, it will probably never be 100% compatible -- I don't think 
> reimplementing all of TeX is feasible or desirable, and the fact that it 
> is a macro language makes it hard to fully emulate. Defining what is a 
> "hack" vs. normal usage is also subjective, of course...
No, of course, but you are making some progress in this direction, and I
think that would be a great added value coming from your work.
Cheers,
Gaël

Gael Varoquaux wrote:
> On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
> 
>>> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>>> 
>
> 
>> Except for the backward incompatibility, I like this because it is explicit.
>> 
>
> Juust a data point for the discussion. I think it would be very nice if a
> script gave the same result on a system with or without TeX (as long as
> you don't do TeX hacks).
> 
Using this "mathtext=True" option (as opposed to using a delimiter that 
TeX doesn't understand) or something else entirely, would certainly make 
it easier to make usetex vs. not usetex more consistent.
More broadly, it will probably never be 100% compatible -- I don't think 
reimplementing all of TeX is feasible or desirable, and the fact that it 
is a macro language makes it hard to fully emulate. Defining what is a 
"hack" vs. normal usage is also subjective, of course...
Cheers,
Mike

On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)
> Except for the backward incompatibility, I like this because it is explicit.
Juust a data point for the discussion. I think it would be very nice if a
script gave the same result on a system with or without TeX (as long as
you don't do TeX hacks).
My 2 cents,
Gaël

John Hunter wrote:
> Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
> 
Except for the backward incompatibility, I like this because it is explicit.
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.
That's close to what it does at the moment.
> Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option.
I'm not sure the performance hit would be so bad. The parser is 
completely flat until it goes between the $'s. But it would require all 
$'s to be escaped, of course.
> In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
> 
Well, that certainly is no shortage of options! ;) I think the decision 
should ultimately lie with someone with a better sense of the existing 
"feel" of matplotlib than I.
If we go with another delimiter, there are others in TeX to choose 
from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both 
of these are less likely to be legitimate literals. While display math 
normally implies that the math is placed on a separate line (not inline 
with the text), it's not far from what matplotlib does, since it follows 
the display math layout patterns.
Cheers,
Mike

A problem was reported on the users list that saving to a file named
'blah.pdf' using the wxagg backend actually saves a jpeg file named
'blah.pdf.jpg'. I think I can see how to fix this (by adding a block to
FigureCanvasWx.print_figure() similar to the existing blocks for ps and
svg), but would prefer to leave it to someone who actually works with
wx, in case I accidentally break something and never notice. I'll file a
bug on sourceforge.
Overall, the system for determining file format looks like it has
evolved and not been designed: various backends have their own code to
look at the file name extension and then switch to the proper backend.
Wouldn't it make sense to share at least the code that determines the
backend from the extension?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"John Hunter" <jd...@gm...> writes:
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.
Those users are probably also not so likely to want to use mathtext, so
there could be an rc setting for toggling the meaning of $ between the
currency symbol and the math delimiter. Adding rc settings is probably
not good for the API, though.
Is it an option to use something rarer than $ to delimit formulas? Most
of the printable ASCII characters are probably being used by someone,
and the unprintable characters are likely to be difficult to handle. ISO
Latin 1 contains e.g. the little-used currency sign ¤. But perhaps it is
too difficult to type on US keyboards?
(There is a Unicode Technical Note at http://unicode.org/notes/tn28/
which suggests using U+23A8 LEFT CURLY BRACKET MIDDLE PIECE and U+23AC
RIGHT CURLY BRACKET MIDDLE PIECE as math delimiters, but it also has its
own Unicode-based math syntax.)
> Option 1 is to educate them, and require them to \$ quote that symbol.
I guess Option 1' is to move away from $ to something else, and educate
mathtext users. If there are fewer of them (us), this would seem to be
easier globally.
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
You're right that it would be quite different than the rest of the API.
Perhaps your Option 2 (a text property) would cause the least surprise
in the long run, although it would break current mathtext-using code.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 7/26/07, Darren Dale <dd...@co...> wrote:
> On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:
> > This sounds to me like a good case for Guido's mantra of NOT putting
> > keywords in functions and instead just making two separate functions.
> > Why not just
> >
> > text(x,y,"This year I lost a lot of $$$")
> > mtext(x,y,r"This year I lost \$$\infty$")
> >
> > ? Explicit is better than implicit and all that...
>
> what about x/ylabels, titles, ticks, etc?
Oh, I'd forgotten about all of those :) Yes, this is pervasive across
MPL, I answered in haste. Duplicating the entire text-related API may
be a tad much, perhaps ;)
> I think education is the best way to go. Its not that difficult to grasp, its
> an established standard... and we are designing tools primarily for
> scientists and engineers after all. Most of the other options will probably
> have a larger effect on existing code.
Well, I was trying to go with John's concern for non-latex users. I'm
quite happy with a system that treats *every string* via latex. But I
know for many reasons that's not realistic here (and PyX does
precisely that, if I really want it).
Cheers,
f

On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:
> [ That was meant for the list, sorry ]
>
> On 7/26/07, John Hunter <jd...@gm...> wrote:
> > I'm on the fence as to how to handle this case. The majority of our
> > users will think of $ as the US currency symbol, and will have never
> > heard of TeX. Option 1 is to educate them, and require them to \$
> > quote that symbol. Option 2 is to enable a text property eg mathtext,
> > and do
> >
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)
But would this make sense:
text(x, y, 'what is the $\sin(x)$', mathtext=False)
[...]
> This sounds to me like a good case for Guido's mantra of NOT putting
> keywords in functions and instead just making two separate functions.
> Why not just
>
> text(x,y,"This year I lost a lot of $$$")
> mtext(x,y,r"This year I lost \$$\infty$")
>
> ? Explicit is better than implicit and all that...
what about x/ylabels, titles, ticks, etc?
I think education is the best way to go. Its not that difficult to grasp, its 
an established standard... and we are designing tools primarily for 
scientists and engineers after all. Most of the other options will probably 
have a larger effect on existing code.
Darren

[ That was meant for the list, sorry ]
On 7/26/07, John Hunter <jd...@gm...> wrote:
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX. Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text. Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option. In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
I'm not Michael, but I s'pose I can still speak :)
This sounds to me like a good case for Guido's mantra of NOT putting
keywords in functions and instead just making two separate functions.
Why not just
text(x,y,"This year I lost a lot of $$$")
mtext(x,y,r"This year I lost \$$\infty$")
? Explicit is better than implicit and all that...
cheers,
f

On 7/26/07, Darren Dale <dd...@co...> wrote:
> > where Math is a wrapper object that signals to "text" that its contents
> > are to be passed to the mathtext interpreter.
>
> I would like to voice my opinion against this idea. I think the backward
> imcompatibility will be rare, and does not justify the additionaly complexity
> of the far more common need to interpret mathtext.
I'm on the fence as to how to handle this case. The majority of our
users will think of $ as the US currency symbol, and will have never
heard of TeX. Option 1 is to educate them, and require them to \$
quote that symbol. Option 2 is to enable a text property eg mathtext,
and do
text(x, y, 'what is the $\sin(x)$', mathtext=True)
Option 3 is to try and be clever, and interpret an even number of
unquoted dollar symbols as mathtext, or any string that has a quoted
dollar sign symbol as mathtext, else assume plain text. Option 4 is
to treat *all* strings as mathtext, but I think we would pay a pretty
big performance hit to invoke the mathtext machinery for every piece
of text. But it is an option. In option 4, of course, users would be
required to quote all dollar signs, so it is related to option 1 but
slightly different in how it treats strings with no dollar signs.
I'm not too keen on the text(x, y, Math('string')) proposal, which is
a little outside the normal matplotlib approach.
Michael, do you have a preference or an alternate proposal?
JDH

On Thursday 26 July 2007 5:54:18 pm Jouni K. Sepp=E4nen wrote:
> It seems that the improvements finally allow users to mix mathtext with
> ordinary text, as in 'foo $a=3Db^c+d$ bar', which I believe has been
> requested a lot. This is really cool, but I think it causes another
> backward incompatibility: you could use dollar signs in text strings
> (except if you wanted a dollar sign both at the beginning and at the end
> of a string), but now dollar signs only work if you use an odd number of
> them.
>
> My suggestion is to distinguish between mathtext and normal text at a
> level outside the string. For example,
>
> text(['foo ', Math(r'a=3Db^c+d'), ' bar'])
>
> where Math is a wrapper object that signals to "text" that its contents
> are to be passed to the mathtext interpreter.
I would like to voice my opinion against this idea. I think the backward=20
imcompatibility will be rare, and does not justify the additionaly complexi=
ty=20
of the far more common need to interpret mathtext.
Darren

It seems that the improvements finally allow users to mix mathtext with
ordinary text, as in 'foo $a=b^c+d$ bar', which I believe has been
requested a lot. This is really cool, but I think it causes another
backward incompatibility: you could use dollar signs in text strings
(except if you wanted a dollar sign both at the beginning and at the end
of a string), but now dollar signs only work if you use an odd number of
them.
My suggestion is to distinguish between mathtext and normal text at a
level outside the string. For example,
 text(['foo ', Math(r'a=b^c+d'), ' bar'])
where Math is a wrapper object that signals to "text" that its contents
are to be passed to the mathtext interpreter.
Or, Math could be a function that parses the string and returns a
lower-level description (presumably a hierarchy of boxes) that "text"
can then intersperse with the simple boxes containing the ordinary
strings. Then we could also have a LaTeX object that passes its argument
to an external LaTeX process, reads the resulting dvi file and returns 
a list of glyphs and rules that "text" knows how to draw on the canvas. 
In other words, formulas could be interpreted by the internal mathtext
parser or the external LaTeX process selectively, not via a single
global usetex switch.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Darren Dale wrote:
> I am working on reorganizing our config system to work with Fernando's 
> tconfig, and I could use some advice. Currently, a lot of the configuration 
> code lives in __init__.py and rcsetup.py. I am thinking of a layout like 
> this:
> 
> matplotlib/lib/matplotlib/
> __init__
> ... 
> config/
> api # mpl's entry point: all imports come from here
> checkdep # checks for dependencies like ghostscript, dvipng, etc.
> configobj # external project, required by tconfig
> cutils # configuration utilities, like get_home, is_writable_dir, etc.
> mplconfig.py # reads new config files using tconfig
> mpltraits # defines mpl traits like colors, markers, linestyles
> rcparams # configuration using old matplotlibrc files
> rcsetup # provides defaults, setup, for rcparams
> tconfig # Fernando's traited config, requires traits and configobj
> verbose # defines the Verbose class used throughout mpl
> 
> the __init__ file would import from config.api: rcParams, which would be the 
> existing dict if the old config system is active, or a dict wrapping the new 
> config object, along with rc, rcdefaults, etc.
> 
> Does this sound reasonable, or could anyone suggest a better organization? 
> Should every trait used by mpl be defined in mpltraits, that is, should 
> mpltraits provide an interface to enthought traits? Or should mpltraits only 
> provide traits that are not predefined by enthought? Is config/ a bad place 
> for verbose?
I don't see any point in having mpltraits provide anything that is 
predefined; at most you could list in comments or the docstring the 
predefined traits that are being used.
The Verbose class could be more generally useful than just for mpl 
config, but this is true of cbook and of at least some of the things you 
will put in cutils. Your proposed config location is OK, but I wonder 
whether it would not be better to consolidate all of these utility 
things that have no dependencies into a single namespace that can be 
imported without pulling in the whole mpl configuration machinery at the 
same time.
I *think* that maybe this is the big advantage of using a minimal 
matplotlib/__init__.py and letting matplotlib/api.py be the normal entry 
point. It means you can do "from matplotlib import cbook", for example, 
and nothing gets executed other than cbook (in the extreme case where 
matplotlib/__init__.py is empty). If you have all sorts of things in 
matplotlib/__init__.py, including the global rcParams, then you can't 
access cbook.is_stringlike, for example, without doing the whole 
creation of rcParams. So, the approach of using minimal __init__.py at 
the base package level helps reduce the problems of circular imports and 
makes the whole package structure more modular.
The problem for us in making that change is that all present code (user 
and internal) that reads "import matplotlib as mpl", for example, would 
have to be changed to "import matplotlib.api as mpl". This is easy to 
do internally, but the breakage of user code is a problem.
I'm an amateur; I trust the experts will promptly straighten out any 
errors in my conjectures above.
Eric

On Thursday 26 July 2007 02:29:26 pm Eric Firing wrote:
> Darren Dale wrote:
> > On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
> >> Are traits going to be a dependency that I have to download and install,
> >> or will all the traits stuff be bundled with mpl?
> >
> > That hasn't been determined yet.
>
> Does your config system run with the old version of traits that is
> *already* bundled with mpl, or does it require a newer version?
I'm not sure if it can work with what is already in the tree or not. It might 
be as simple as changing
import enthought.traits.api as traits
to
import matplotlib.enthought.traits as traits
but I havent tried yet, and wont be in a position to do so for a day or two.

Darren Dale wrote:
> On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
>> Are traits going to be a dependency that I have to download and install, or
>> will all the traits stuff be bundled with mpl?
> 
> That hasn't been determined yet.
Does your config system run with the old version of traits that is 
*already* bundled with mpl, or does it require a newer version?
Eric

On 7/26/07, Darren Dale <dd...@co...> wrote:
> On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
> > Are traits going to be a dependency that I have to download and install, or
> > will all the traits stuff be bundled with mpl?
>
> That hasn't been determined yet.
Just as a data point, I think we (ipython) will ship a private copy of
traits for a while, until the dust settles. I know this goes against
Enthought's wishes, but they are still having repository
reorganizations, and I just want to make sure that for *our users*,
the existence of traits is 100% a non-issue, purely an internal
implementation detail.
In ipython1, we have an externals/ package where we shove any external
project we ship a copy of. Then we do in our code
from ipython1.externals import foo
and move on.
That centralizes things, and if at some point 'foo' becomes
stable/easy enough to rely on from upstream, the changes are trivial.
Cheers,
f

On 7/26/07, Darren Dale <dd...@co...> wrote:
> On Thursday 26 July 2007 10:30:34 am Ted Drain wrote:
> > Darren,
> > Well it wasn't one of your questions but...
> >
> > Why do you need an api file at all? Why not have config be a python
> > package and let config/__init__.py take care of importing
> > everything? The __init__ file of a package is responsible for
> > configuring the api of a package so it seems redundent to have
> > another filed named api.
>
> Good suggestion. I was emulating the way traits and IPython1 are doing it, but
> probably __init__ is better and cleaner.
I don't remember the exact details, but we started using the api.py
approach instead of __init__ on Enthought's lead (I think to be more
friendly to setuptools, perhaps it had something to do with namespace
packages). There were discussions a while ago on the Enthought lists
about the reasons why they were moving away from __init__. While it
kind of bothered me a bit in the beginning out of an "If it ain't
broke, don't fix it" view, I realized that they seemed to have
thought it through.
You may want to inquire with them for the details (I was only paying
marginal attention and relied on trusting that they *did* think it
through) and then decide whether the reasons do/will/may apply to MPL
as well. But it didn't happen by accident, it was a deliberate
choice.
Cheers,
f

On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
> Are traits going to be a dependency that I have to download and install, or
> will all the traits stuff be bundled with mpl?
I should also have mentioned, for those of you not following the older thread: 
the new system is somewhat speculative. The old system will be the default 
while we investigate a new option. I don't know when the new one would be 
ready to go live, or whether we will adopt it when it is ready.

On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
> Are traits going to be a dependency that I have to download and install, or
> will all the traits stuff be bundled with mpl?
That hasn't been determined yet.

Are traits going to be a dependency that I have to download and install, or will all the traits stuff be bundled with mpl? 
-- 
Tom Holroyd, Ph.D.
"The fundamentally misconceived nature versus nurture debate should be
abandoned: child development is inextricably both." -- Louann Brizendine

On Thursday 26 July 2007 10:30:34 am Ted Drain wrote:
> Darren,
> Well it wasn't one of your questions but...
>
> Why do you need an api file at all? Why not have config be a python
> package and let config/__init__.py take care of importing
> everything? The __init__ file of a package is responsible for
> configuring the api of a package so it seems redundent to have
> another filed named api.
Good suggestion. I was emulating the way traits and IPython1 are doing it, but 
probably __init__ is better and cleaner.

Darren,
Well it wasn't one of your questions but...
Why do you need an api file at all? Why not have config be a python 
package and let config/__init__.py take care of importing 
everything? The __init__ file of a package is responsible for 
configuring the api of a package so it seems redundent to have 
another filed named api.
Ted
At 07:26 AM 7/26/2007, Darren Dale wrote:
>I am working on reorganizing our config system to work with Fernando's
>tconfig, and I could use some advice. Currently, a lot of the configuration
>code lives in __init__.py and rcsetup.py. I am thinking of a layout like
>this:
>
>matplotlib/lib/matplotlib/
> __init__
> ...
> config/
> api # mpl's entry point: all imports come from here
> checkdep # checks for dependencies like ghostscript, dvipng, etc.
> configobj # external project, required by tconfig
> cutils # configuration utilities, like get_home, 
> is_writable_dir, etc.
> mplconfig.py # reads new config files using tconfig
> mpltraits # defines mpl traits like colors, markers, linestyles
> rcparams # configuration using old matplotlibrc files
> rcsetup # provides defaults, setup, for rcparams
> tconfig # Fernando's traited config, requires traits and configobj
> verbose # defines the Verbose class used throughout mpl
>
>the __init__ file would import from config.api: rcParams, which would be the
>existing dict if the old config system is active, or a dict wrapping the new
>config object, along with rc, rcdefaults, etc.
>
>Does this sound reasonable, or could anyone suggest a better organization?
>Should every trait used by mpl be defined in mpltraits, that is, should
>mpltraits provide an interface to enthought traits? Or should mpltraits only
>provide traits that are not predefined by enthought? Is config/ a bad place
>for verbose?
>
>Thanks,
>Darren
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

I am working on reorganizing our config system to work with Fernando's 
tconfig, and I could use some advice. Currently, a lot of the configuration 
code lives in __init__.py and rcsetup.py. I am thinking of a layout like 
this:
matplotlib/lib/matplotlib/
 __init__
 ... 
 config/
 api # mpl's entry point: all imports come from here
 checkdep # checks for dependencies like ghostscript, dvipng, etc.
 configobj # external project, required by tconfig
 cutils # configuration utilities, like get_home, is_writable_dir, etc.
 mplconfig.py # reads new config files using tconfig
 mpltraits # defines mpl traits like colors, markers, linestyles
 rcparams # configuration using old matplotlibrc files
 rcsetup # provides defaults, setup, for rcparams
 tconfig # Fernando's traited config, requires traits and configobj
 verbose # defines the Verbose class used throughout mpl
the __init__ file would import from config.api: rcParams, which would be the 
existing dict if the old config system is active, or a dict wrapping the new 
config object, along with rc, rcdefaults, etc.
Does this sound reasonable, or could anyone suggest a better organization? 
Should every trait used by mpl be defined in mpltraits, that is, should 
mpltraits provide an interface to enthought traits? Or should mpltraits only 
provide traits that are not predefined by enthought? Is config/ a bad place 
for verbose?
Thanks,
Darren