On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know
On 7/22/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> the other hand, I can't be too enthusiastic about pushing for inclusion in
> matplotlib in the near future, because I havent been able to install traits
> as a separate package. At the moment, the following command
Well, we always have matplotli
On Sun, Jul 22, 2007 at 11:43:31AM -0400, Darren Dale wrote:
> The issue of configuration has come up several times on the mailing
> lists over the last few years, and Fernando's tconfig feels like the
> right solution. On the other hand, I can't be too enthusiastic about
> pushing for inclusion in
Hi John,
On Sunday 22 July 2007 9:51:05 am John Hunter wrote:
> On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > 2) It would be nice to be able to write a default file that has
> > everything commented out with the exception of backend.use and numerix.
> > We comment out all the parameters i
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try you
>> Im attaching a patch
> Is the patch against current SVN?
It was one version out of date. Here is a new one, against 2533
Index: mpltest.py
===
--- mpltest.py (revision 2533)
+++ mpltest.py (working copy)
@@ -5,43 +5,14 @@
import
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know
On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > I'm working on converting our existing rc code to tconfig this weekend.
> > So far so good. I just wanted to let people know to avoid duplicating
> > effort.
>
> Excellent! Ping me if
On 7/21/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> I'm working on converting our existing rc code to tconfig this weekend. So far
> so good. I just wanted to let people know to avoid duplicating effort.
Excellent! Ping me if you have any problems.
I'm going to try and finish hierarchical incl
On Friday 20 July 2007 5:13:12 pm Fernando Perez wrote:
> On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > > This should give you a very reasonable solution for what you wanted to
> > > do.
> >
> > Great! I'm surprised that this was possible.
>
> And actually easy, for once.
>
> > Im attachin
On Fri, Jul 20, 2007 at 03:25:06PM -0600, Fernando Perez wrote:
> The point is that instead of
> -from mplconfig import MPLConfig, ConfigManager, mkConfigObj
> I prefer:
> +from tconfig import ConfigManager, mkConfigObj
> +from mplconfig import MPLConfig
> since ConfigManager and mkConfigObj re
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote:
> > I also just (r2528) updated things to use a cleaner import convention:
> > I don't like importing things from modules *they* imported.
> [...]
> > The point is that instead of
> >
> > -
On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote:
> I also just (r2528) updated things to use a cleaner import convention:
> I don't like importing things from modules *they* imported.
[...]
> The point is that instead of
>
> -from mplconfig import MPLConfig, ConfigManager, mkConfigObj
>
> I
On 7/20/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>
> > > This should give you a very reasonable solution for what you wanted to do.
> >
> > Great! I'm surprised that this was possible.
>
> And actually easy, for once.
>
> > Im attaching a pa
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > This should give you a very reasonable solution for what you wanted to do.
>
> Great! I'm surprised that this was possible.
And actually easy, for once.
> Im attaching a patch for the ipython1 sandbox, which adds configobj.py, moves
> the ip
Fernando Perez wrote:
> Am I missing something?
No, I just wasn't paying close enough attention. Never mind me.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underly
On 7/20/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Darren Dale wrote:
>
> > That is not too bad for small config files, but matplotlib's selection of rc
> > parameters is pretty large, and it is nice to have them appear in the file
> > in
> > a meaningful order.
>
> You guys may want to consider
Darren Dale wrote:
> That is not too bad for small config files, but matplotlib's selection of rc
> parameters is pretty large, and it is nice to have them appear in the file in
> a meaningful order.
You guys may want to consider iniparse instead of configobj. It will preserve
order, indentatio
On 7/20/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> However, it's not all gloom and doom: one can simply generate a config
> file from the object description, edit it for ordering, and after that
> keep it synced with changes to the object description fairly easily.
> The current code only wor
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> Although, the config files generated this way are not very well organized, due
> to the seemingly random order that a dict's items are accessed. Look at the
> mpl3.conf file that is generated with Fernando's proof-of-concept:
>
> interactive = F
On Friday 20 July 2007 12:31:00 pm Brian Granger wrote:
> > Damn, that is really cool. So you can generate default config files from
> > the MPLConfig instance. We create a default matplotlibrc file from a
> > template, setting default backend and numerix values based on what is
> > available on th
> 3. Traits. We (Brian and I) have gone back and forth a lot on Traits,
> and we've come very close to just making them a dependency. The only
> real issue holding us back is that ipython so far has exactly *zero*
> extension code, which is a plus in terms of ease of
> installation/deployment. H
> Damn, that is really cool. So you can generate default config files from the
> MPLConfig instance. We create a default matplotlibrc file from a template,
> setting default backend and numerix values based on what is available on the
> users system. It looks like it would be even easier with your
On Wed, Jul 18, 2007 at 11:24:09AM -0600, Brian Granger wrote:
> At some level though, configuration is a very different thing than an
> application's runtime API. While they may be related (by exposing
> common functionality), not everything that can be configured would
> appear in a runtime API
On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> Damn, that is really cool. So you can generate default config files from the
> MPLConfig instance. We create a default matplotlibrc file from a template,
> setting default backend and numerix values based on what is available on the
> users syst
On Thursday 19 July 2007 8:02:53 pm Fernando Perez wrote:
> - Consider a file called mpl.conf:
> # Top-level
> backend = "TkAgg"
> interactive = False
>
> # Things that can only be set at init time, they become read-only
> afterwards
> [InitOnly]
> numerix = "numpy"
[...]
> - Then, consider the f
On 7/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> > 3. Traits. We (Brian and I) have gone back and forth a lot on Traits,
> > and we've come very close to just making them a dependency. The only
> > real issue holding us back is that ipython so far has exactly *zero*
> > extension code, whi
Hi all,
this is an important discussion also for us (ipython), so I'll go in
some detail into things. It would be great if out of this we got
something that both ipython and matplotlib could reuse for the long
haul, though I'm not sure (in a sense, ipython has some nastier
requirements that mpl m
On 7/17/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> TraitsUI seems really cool, but there are a couple of reasons I think
> that should probably be considered lower priority. For one, it would
> need to be generalized and ported (backend-ed) for all of matplotlib's
> many gui backends. A
Sorry for double posting. Apparently the original posting was html formatted,
and looked nonsensical. Hopefully this one is more clear:
On Tuesday 17 July 2007 02:31:02 pm Darren Dale wrote:
> On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> > Speaking of branches, we may need to seriousl
On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> Speaking of branches, we may need to seriously consider a branch here,
> mpl1.
I vote for a branch. Maybe we could consider an alternative directory layout in
a branch, the current layout is a bit entropic. For the sake of discussion:
mpl/
Christopher Barker wrote:
> I have thought about the safety issue. One idea I've had (though I never
> bothered with it) was to strip the input files of "import" lines first.
> You could do a whole lot less if you couldn't import any arbitrary modules.
Disallowing import statements won't help w
Darren Dale wrote:
> John, Eric, have you had a look at the way IPython1 handles config files?
> Here's a taste:
> In ipython's scheme, the config files
> are loaded using execfile, I wonder if that might appear unsafe to anyone?
This is, of course, terribly unsafe, but does anyone have a use
On Tuesday 17 July 2007 11:22:29 am John Hunter wrote:
> On 7/17/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> > I'd like to add the dict-based validation scheme for 0.91. It should be
> > quick, and then I can focus on traits and a new config scheme, in an mpl1
> > branch if we decide that is best.
On 7/17/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> I'd like to add the dict-based validation scheme for 0.91. It should be quick,
> and then I can focus on traits and a new config scheme, in an mpl1 branch if
> we decide that is best.
Sounds like a good plan.
--
On Tuesday 17 July 2007 09:33:47 am John Hunter wrote:
> We should also consider getting out a 0.91 release as soon as we can
> finish the numpification, because Michael has done a lot of good work.
> So much to do
I'd like to add the dict-based validation scheme for 0.91. It should be quick,
On 7/17/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> I'm really impressed with how readable and well organized the code is in
> ipython1. It looks like their approach to configuration has been carefully
> considered. Any chance we can follow their lead? It looks like it would be a
I haven't looke
On Tuesday 17 July 2007 09:15:15 am Darren Dale wrote:
> I'm really impressed with how readable and well organized the code is in
> ipython1. It looks like their approach to configuration has been carefully
> considered. Any chance we can follow their lead? It looks like it would be
> a good fit: w
On Tuesday 17 July 2007 08:01:41 am Michael Droettboom wrote:
> Gael Varoquaux wrote:
> > On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> >> I am happy to be the first at this point -- enthought has done a lot
> >> to support traits. Traits has one of the most impressive pieces of
>
On Tue, Jul 17, 2007 at 08:01:41AM -0400, Michael Droettboom wrote:
> TraitsUI seems really cool, but there are a couple of reasons I think
> that should probably be considered lower priority. For one, it would
> need to be generalized and ported (backend-ed) for all of matplotlib's
> many gui
Gael Varoquaux wrote:
> On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
>
>> I am happy to be the first at this point -- enthought has done a lot
>> to support traits. Traits has one of the most impressive pieces of
>> technical documentation in the scientific python community.
>>
On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> > Are any real, live projects outside of enthought making major use of
> > traits? Or would we be the first?
> I am happy to be the first at this point -- enthought has done a lot
Robert Kern wrote:
[...]
> We've split up the main "enthought" package such that Traits can be installed
> separately as "enthoguht.traits". I think we'd prefer depending on it
> externally
> now that we've spent so much effort to make that feasible.
When do you expect to make a release?
Eric
-
John Hunter wrote:
> On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>> Are any real, live projects outside of enthought making major use of
>> traits? Or would we be the first?
Yes. Most are in the somewhat formative stages, so you may not think they count
(which is fine).
> I am happy to
On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> Are any real, live projects outside of enthought making major use of
> traits? Or would we be the first?
I am happy to be the first at this point -- enthought has done a lot
to support traits. Traits has one of the most impressive pieces of
t
John Hunter wrote:
[...]
> Isn't there a potential problem here? The original validate funcs
> support conversion from a string to a value, but you are proposing
> using them here in a context where users will generally be supplying a
> (possibly bogus) value, but in general not a string. So the
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should also
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should als
On Monday 16 July 2007 7:22:37 pm you wrote:
> Darren Dale wrote:
> > I've been thinking a bit about rcParams and validation. It looks like
> > values are currently only validated when matplolibrc is read, during the
> > call to rc_params. What if we define a new class (RcParams), derived from
> >
Darren Dale wrote:
> I've been thinking a bit about rcParams and validation. It looks like values
> are currently only validated when matplolibrc is read, during the call to
> rc_params. What if we define a new class (RcParams), derived from dict, which
> has as an attribute, a dict, called vali
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> the validation dict and default properties would be populated during the
> initial call to rc_params(), when the defaultParams dict is interpretted.
> Thereafter, any attempt to set a parameter, either directly using
> rcParams[i]=j or indirectly
52 matches
Mail list logo
