Hey,
I am about to start a configuration file for mayavi's mlab, and I am
strongly considering mimicking matplotlib's way of doing things.
I am almost sold to Fernando's TConfig, but I am not too sure how this
fits with the current rcParams dictionnary. Is there some code that I
could study to see how it's done?
Cheers,
Ga�l
Hi Gael,
On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote:
I am about to start a configuration file for mayavi's mlab, and I am
strongly considering mimicking matplotlib's way of doing things.I am almost sold to Fernando's TConfig, but I am not too sure how this
fits with the current rcParams dictionnary. Is there some code that I
could study to see how it's done?
Look in matplotlib/config/mplconfig.py, there is a class called
RcParamsWrapper that was designed to make the transition from rcParams to
TConfig easy for both developers and users. It should make the relationship
between the two pretty clear.
Darren
OK, thanks.
In the long run, what do you suggest I implement for mayavi2, an object
oriented interface (pure TConfig) or an dictionnary-like interface
(your RcParamsWrapper)?
I am not too exited about your RcParamsWrapper because it is not
generated from the configuration object, and thus the info is duplicated,
but I guess you did this for backward compatibility reasons, and I could
use a canonical mapping from one to the other and do this automatically.
I would like to proivde an interface that feels familiar to the user,
this is why I am looking closely at what MPL and ipython are doing.
Cheers,
Ga�l
On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote:
Hi Gael,
On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote:
> I am about to start a configuration file for mayavi's mlab, and I am
> strongly considering mimicking matplotlib's way of doing things.
> I am almost sold to Fernando's TConfig, but I am not too sure how this
> fits with the current rcParams dictionnary. Is there some code that I
> could study to see how it's done?
Look in matplotlib/config/mplconfig.py, there is a class called
RcParamsWrapper that was designed to make the transition from rcParams to
TConfig easy for both developers and users. It should make the relationship
between the two pretty clear.
RcParamsWrapper was created so we could get matplotlib working with the new
config object without a massive rewrite of the entire library. The intention
is to use the object-oriented interface internally, and to encourage users to
do the same. RcParamsWrapper simply provides the upgrade path.
Darren
On Tuesday 11 December 2007 7:03:57 pm Gael Varoquaux wrote:
On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote:
> Hi Gael,
>
> On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote:
> > I am about to start a configuration file for mayavi's mlab, and I am
> > strongly considering mimicking matplotlib's way of doing things.
> >
> > I am almost sold to Fernando's TConfig, but I am not too sure how this
> > fits with the current rcParams dictionnary. Is there some code that I
> > could study to see how it's done?
>
> Look in matplotlib/config/mplconfig.py, there is a class called
> RcParamsWrapper that was designed to make the transition from rcParams to
> TConfig easy for both developers and users. It should make the
> relationship between the two pretty clear.OK, thanks.
In the long run, what do you suggest I implement for mayavi2, an object
oriented interface (pure TConfig) or an dictionnary-like interface
(your RcParamsWrapper)?I am not too exited about your RcParamsWrapper because it is not
generated from the configuration object, and thus the info is duplicated,
but I guess you did this for backward compatibility reasons, and I could
use a canonical mapping from one to the other and do this automatically.I would like to proivde an interface that feels familiar to the user,
this is why I am looking closely at what MPL and ipython are doing.
OK, Thanks a lot. I'll probably stick with pure objects, than, but I
might modify the __repr__ of the object to make it more easily for the
user to edit this interactively (ie making a representation more like to
one you would get out of a dictionnary.
The problem is that it would break your script, so I can't send you a
patch. I'd like the codebase to stay similar, so maybe we can discuss
this once I have some code.
Ga�l
On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote:
RcParamsWrapper was created so we could get matplotlib working with the new
config object without a massive rewrite of the entire library. The intention
is to use the object-oriented interface internally, and to encourage users to
do the same. RcParamsWrapper simply provides the upgrade path.
> RcParamsWrapper was created so we could get matplotlib working with the new
> config object without a massive rewrite of the entire library. The intention
> is to use the object-oriented interface internally, and to encourage users to
> do the same. RcParamsWrapper simply provides the upgrade path.OK, Thanks a lot. I'll probably stick with pure objects, than, but I
might modify the __repr__ of the object to make it more easily for the
user to edit this interactively (ie making a representation more like to
one you would get out of a dictionnary.
The tconfig objects already have a very dict-like representation for
dumping into a text file, the .ini format. Or do you mean something
that's even closer to a dict, curly braces and all?
The problem is that it would break your script, so I can't send you a
patch. I'd like the codebase to stay similar, so maybe we can discuss
this once I have some code.
Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
mayavi-tconfig 
Cheers,
f
On Dec 11, 2007 5:32 PM, Gael Varoquaux <gael.varoquaux@...427...> wrote:
On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote:
The tconfig objects already have a very dict-like representation for
dumping into a text file, the .ini format. Or do you mean something
that's even closer to a dict, curly braces and all?
No, I don't care about the curly brace. However, I don't want the
comments. I haven't decided yet, but I am sure that I want something that
a bit more compact than, eg "print MPLConfig()".
> The problem is that it would break your script, so I can't send you a
> patch. I'd like the codebase to stay similar, so maybe we can discuss
> this once I have some code.
Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
mayavi-tconfig
Yes, lets try to keep this united. I'll probably also work on a nice
TraitsUI view. If all three projects can use the same model, view and
controler for the configuration file, that will make it easier to, one
day, present a unified configuration editor for a scientific IDE (:->).
Ga�l
On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote:
> The tconfig objects already have a very dict-like representation for
> dumping into a text file, the .ini format. Or do you mean something
> that's even closer to a dict, curly braces and all?No, I don't care about the curly brace. However, I don't want the
comments. I haven't decided yet, but I am sure that I want something that
a bit more compact than, eg "print MPLConfig()".
I see, makes sense. Hack away, I trust your judgment
> > The problem is that it would break your script, so I can't send you a
> > patch. I'd like the codebase to stay similar, so maybe we can discuss
> > this once I have some code.> Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
> mayavi-tconfigYes, lets try to keep this united. I'll probably also work on a nice
TraitsUI view. If all three projects can use the same model, view and
controler for the configuration file, that will make it easier to, one
day, present a unified configuration editor for a scientific IDE (:->).
Indeed. Once we have the code in place, we'll worry about organizing
things for easy reuse.
Cheers,
f
On Dec 11, 2007 5:42 PM, Gael Varoquaux <gael.varoquaux@...427...> wrote:
On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote: