[matplotlib-devel] organization of traited config system
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On Thursday 26 July 2007 5:54:18 pm Jouni K. Seppänen wrote: > 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. 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. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On 7/26/07, Darren Dale <[EMAIL PROTECTED]> 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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
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 <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
[ That was meant for the list, sorry ]
On 7/26/07, John Hunter <[EMAIL PROTECTED]> 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
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On 7/26/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
On 7/26/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
On 7/26/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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 >Matplotlib-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
