matplotlib-devel Mailing List for matplotlib

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