Hi all,
if anyone is still following, please update the tconfig work. Run
ipython -wthread
%run mpltest.py
mplconf2.tconf.edit_traits()
Edit to your heart's content.
You can then save changes via
mplconf2.write()
Cheers,
f
ps - the auto-generated file now has all class docstrings as comments
as well as traits handlers info. It should be a pretty good start for
a manually tweaked one.
pps - I'm done with this, for a while. I've sunk *way* too much time into it.
I am not running in wthred, but I think there may be an import problem somewhere
In [3]: run mpltest.py
On 7/24/07, Fernando Perez <fperez.net@...149...> wrote:
Hi all,
if anyone is still following, please update the tconfig work. Run
ipython -wthread
%run mpltest.py
mplconf2.tconf.edit_traits()Edit to your heart's content.
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/Users/jdhunter/tmp/sandbox/tconfig/mpltest.py in <module>()
10
11 mconf = 'mplrc.conf'
---> 12 mplconf = RecursiveConfigManager(MPLConfig, mconf, filePriority=True)
13 mplconf.tconf.backend.use = 'Qt4Agg'
14 mplconf.write()
/Users/jdhunter/tmp/sandbox/tconfig/tconfig.py in __init__(self,
configClass, configFilename, filePriority)
442
443 if filePriority:
--> 444 self.tconf = configClass(self.fconfCombined,monitor=monitor)
445 else:
446 # Push defaults onto file object
/Users/jdhunter/tmp/sandbox/tconfig/tconfig.py in __init__(self,
config, parent, monitor)
345 getattr(self,k)
346 scal = getattr(self,k)
--> 347 except TraitError,e:
348 t = self.__class_traits__[k]
349 msg = "Bad key,value pair given: %s -> %s\n" % (k,config[k])
NameError: global name 'TraitError' is not defined
WARNING: Failure executing file: <mpltest.py>
pps - I'm done with this, for a while. I've sunk *way* too much time into it.
We've heard that before 
Hi all,
if anyone is still following, please update the tconfig work. Run
ipython -wthread
%run mpltest.py
mplconf2.tconf.edit_traits()Edit to your heart's content.
I can't get edit_traits() working on my machine, but I can do it with the
command line.
You can then save changes via
mplconf2.write()
The mpltest.py script expects there to be an mplrc2.conf file, but it isnt in
svn. So the script creates an empty mplrc2_copy.conf file, linked with a
default MPLConfig, but if I change some properties of mplconf2.tconf, and
then do mplconf2.write(), the mplrc2_copy.conf file remains blank.
If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my tconf
properties, call write(), and those changes do get updated in
mplrc2_copy.conf.
ps - the auto-generated file now has all class docstrings as comments
as well as traits handlers info. It should be a pretty good start for
a manually tweaked one.
I have not been able to auto-generate a default file. As above, the file is
blank after writing.
pps - I'm done with this, for a while. I've sunk *way* too much time into
it.
Thank you Fernando. I'll have a look at the issues I reported when I get a
chance.
Darren
On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
Line 347 in tconfig.py, change TraitError to T.TraitError
On Tuesday 24 July 2007 7:57:37 am John Hunter wrote:
On 7/24/07, Fernando Perez <fperez.net@...149...> wrote:
> Hi all,
>
> if anyone is still following, please update the tconfig work. Run
>
> ipython -wthread
> %run mpltest.py
> mplconf2.tconf.edit_traits()
>
> Edit to your heart's content.I am not running in wthred, but I think there may be an import problem
somewhere
> Hi all,
>
> if anyone is still following, please update the tconfig work. Run
>
> ipython -wthread
> %run mpltest.py
> mplconf2.tconf.edit_traits()
>
> Edit to your heart's content.I can't get edit_traits() working on my machine, but I can do it with the
command line.
Bummer. It's nice to see that GUI for the whole of MPL running 
> You can then save changes via
>
> mplconf2.write()The mpltest.py script expects there to be an mplrc2.conf file, but it isnt in
svn. So the script creates an empty mplrc2_copy.conf file, linked with a
default MPLConfig, but if I change some properties of mplconf2.tconf, and
then do mplconf2.write(), the mplrc2_copy.conf file remains blank.
Are you sure? I just ran the test removing the mplrc.conf file from
my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
after editing the tconf object and calling write(), I *do* get the
changes I make written to it. I can't reproduce your problem...
If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my tconf
properties, call write(), and those changes do get updated in
mplrc2_copy.conf.> ps - the auto-generated file now has all class docstrings as comments
> as well as traits handlers info. It should be a pretty good start for
> a manually tweaked one.I have not been able to auto-generate a default file. As above, the file is
blank after writing.
How are you trying to generate it? Does the printout on-screen at
least write a full config for you?
Please update and try again, I added a little utility called
tconf2File() to wrap this writing process; there's a small subtlety
that I might not have been clear about before (one has to write the
str() form of the tconf object to get the class docstring extraction).
> pps - I'm done with this, for a while. I've sunk *way* too much time into
> it.Thank you Fernando. I'll have a look at the issues I reported when I get a
chance.
Thanks.
Cheers,
f
On 7/24/07, Darren Dale <dd55@...143...> wrote:
On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
Fixed in SVN, sorry. That's why the last ToDo item on this before
considering it really semi-done is to turn the test scripts into real
doc/unit tests that also exercise the exception-generation codepaths.
Otherwise crap like this creeps in...
Cheers,
f
On 7/24/07, Darren Dale <dd55@...143...> wrote:
On Tuesday 24 July 2007 7:57:37 am John Hunter wrote:
> On 7/24/07, Fernando Perez <fperez.net@...149...> wrote:
> > Hi all,
> >
> > if anyone is still following, please update the tconfig work. Run
> >
> > ipython -wthread
> > %run mpltest.py
> > mplconf2.tconf.edit_traits()
> >
> > Edit to your heart's content.
>
> I am not running in wthred, but I think there may be an import problem
> somewhereLine 347 in tconfig.py, change TraitError to T.TraitError
> > Hi all,
> >
> > if anyone is still following, please update the tconfig work. Run
> >
> > ipython -wthread
> > %run mpltest.py
> > mplconf2.tconf.edit_traits()
> >
> > Edit to your heart's content.
>
> I can't get edit_traits() working on my machine, but I can do it with the
> command line.Bummer. It's nice to see that GUI for the whole of MPL running
I know, I really wanted to see this. Are you using traits from
http://code.enthought.com/enstaller/eggs/source/unstable? I think it has
something to do with my wx, maybe I am out of date, using wx-2.6.3.3:
/usr/lib/python2.5/site-packages/enthought.traits.ui.wx-2.0b2.dev_r12984-py2.5.egg/enthought/traits/ui/wx/ui_panel.py
in create_label(self, item, ui, desc, parent, sizer, suffix, pad_side)
1000 control.help = item.get_help( ui )
1001 sizer.Add( control, 0, self.label_flags |
wx.ALIGN_CENTER_VERTICAL |
-> 1002 pad_side, self.label_pad )
1003 if desc != '':
1004 control.SetToolTipString( 'Specifies ' + desc )
/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py in Add(*args,
**kwargs)
11709 Appends a child item to the sizer.
11710 """
11711 return _core_.Sizer_Add(*args, **kwargs)
11712
11713 def Insert(*args, **kwargs):
<type 'exceptions.TypeError'>: wx.Window, wx.Sizer, wx.Size, or (w,h) expected
for item
> > You can then save changes via
> >
> > mplconf2.write()
>
> The mpltest.py script expects there to be an mplrc2.conf file, but it
> isnt in svn. So the script creates an empty mplrc2_copy.conf file, linked
> with a default MPLConfig, but if I change some properties of
> mplconf2.tconf, and then do mplconf2.write(), the mplrc2_copy.conf file
> remains blank.Are you sure? I just ran the test removing the mplrc.conf file from
my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
after editing the tconf object and calling write(), I *do* get the
changes I make written to it. I can't reproduce your problem...
I updated from svn. If mplrc.conf and mplrc2.conf are both present, I can run
mpltest.py, change mplconf2.tconf.backend.use, call mplconf2.write(), and get
a mplrc2_copy.conf that contains:
# A hierarchical configuration
include = 'mplrc.conf'
[backend]
use = 'WxAgg'
if I delete mplrc.conf, and repeat the exercise, I get a blank mplrc.conf, and
an mplrc2_copy.conf that contains:
# A hierarchical configuration
include = 'mplrc.conf'
If I delete mplrc2.conf, and I make sure that mplrc2_copy.conf has also been
deleted, the exercise yields a blank mplrc2_copy.conf.
tconf2File works nicely. One comment, it is not indented like the files that
are created by tconf.write(), where sections are indented and subsections are
double-indented.
> If I copy mplrc.conf to mplrc2.conf, then I can run mpltest, change my
> tconf properties, call write(), and those changes do get updated in
> mplrc2_copy.conf.
>
> > ps - the auto-generated file now has all class docstrings as comments
> > as well as traits handlers info. It should be a pretty good start for
> > a manually tweaked one.
>
> I have not been able to auto-generate a default file. As above, the file
> is blank after writing.How are you trying to generate it? Does the printout on-screen at
least write a full config for you?
It does. I was creating a RecursiveConfigManager with a string pointing to a
file that does not exist, and then calling that manager's write() method.
Darren
On Tuesday 24 July 2007 11:29:22 am Fernando Perez wrote:
On 7/24/07, Darren Dale <dd55@...143...> wrote:
> On Tuesday 24 July 2007 5:20:40 am Fernando Perez wrote:
> Bummer. It's nice to see that GUI for the whole of MPL running
I know, I really wanted to see this. Are you using traits from
http://code.enthought.com/enstaller/eggs/source/unstable? I think it has
something to do with my wx, maybe I am out of date, using wx-2.6.3.3:
Mmh, dunno what the problem may be. I think I'm using a fairly old
source install (of enthought), before eggs. All my machines are
running Feisty.
> > > You can then save changes via
> > >
> > > mplconf2.write()
> >
> > The mpltest.py script expects there to be an mplrc2.conf file, but it
> > isnt in svn. So the script creates an empty mplrc2_copy.conf file, linked
> > with a default MPLConfig, but if I change some properties of
> > mplconf2.tconf, and then do mplconf2.write(), the mplrc2_copy.conf file
> > remains blank.
>
> Are you sure? I just ran the test removing the mplrc.conf file from
> my disk, and the mpnlrc2_copy.conf file is indeed created blank, but
> after editing the tconf object and calling write(), I *do* get the
> changes I make written to it. I can't reproduce your problem...I updated from svn. If mplrc.conf and mplrc2.conf are both present, I can run
mpltest.py, change mplconf2.tconf.backend.use, call mplconf2.write(), and get
a mplrc2_copy.conf that contains:# A hierarchical configuration
include = 'mplrc.conf'
[backend]
use = 'WxAgg'if I delete mplrc.conf, and repeat the exercise, I get a blank mplrc.conf, and
an mplrc2_copy.conf that contains:# A hierarchical configuration
include = 'mplrc.conf'If I delete mplrc2.conf, and I make sure that mplrc2_copy.conf has also been
deleted, the exercise yields a blank mplrc2_copy.conf.
Just so we save time, would you mind just coding up the failure as a test?
Something like (assuming it's inside mpltest.py, so the imports are done):
def test():
On 7/24/07, Darren Dale <dd55@...143...> wrote:
On Tuesday 24 July 2007 11:29:22 am Fernando Perez wrote:
###
if blah:
raise Error('this is what I don't want')
test()
That way we know *exactly* what each other is trying to say. Maybe
I'm just tired (I am), but I'm not quite understanding the problem
you're seeing or the behavior you'd like/expect.
tconf2File works nicely. One comment, it is not indented like the files that
are created by tconf.write(), where sections are indented and subsections are
double-indented.
Fixed to match the behavior of ConfigObj.write(), please update SVN.
Cheers,
f
Hi Fernando,
Just so we save time, would you mind just coding up the failure as a test?
It is attached. Here is the output on my machine:
copying mplrc.conf to mplrc_copy.conf
loading from mplrc_copy.conf
Backend loaded from file: Qt4Agg
Backend now changed to Cairo in tconfig object
writing file
reloading from mplrc_copy.conf
Backend reloaded from file: Cairo
It should be Cairo
deleting mplrc_copy.conf
mpltest2.py (3.11 KB)
On Tuesday 24 July 2007 1:34:47 pm Fernando Perez wrote:
--------------------------------------------------------------------------------
creating RecursiveConfManager with no_mplrc.conf, which does not exist
calling RecursiveConfigManagers write() method
Here are the contents of no_mplrc.conf:
I might have expected to see the MPLConfig defaults
Backend now changed to: Cairo
calling RecursiveConfigManagers write() method
Here are the new contents of no_mplrc.conf:
in this test, dsd finds that no_mplrc.conf is empty after both writes
I suggest that tconfig should either write to the file, or raise an
error when the file does not exist
removing no_mplrc.conf
--------------------------------------------------------------------------------
moving mplrc.conf to mplrc.conf.off
copying mplrc2.conf to mplrc2_copy.conf
loading config from mplrc2_copy.conf, which includes mplrc.conf-
but mplrc.conf does not exist
here are the contents of mplrc2_copy.conf, as loaded
# A hierarchical configuration
include = 'mplrc.conf'
Backend now changed to: Cairo
writing to file
Here are the new contents of mplrc2_copy.conf:
# A hierarchical configuration
include = 'mplrc.conf'
I might have expected to see the backend.use here
maybe an error should be raised when a config file includes another
config file that does not exist
moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf
--------------------------------------------------------------------------------
Hi Fernando,
> Just so we save time, would you mind just coding up the failure as a test?
It is attached. Here is the output on my machine:
Great, thanks. Please update. My comments are inlined now:
copying mplrc.conf to mplrc_copy.conf
loading from mplrc_copy.conf
Backend loaded from file: Qt4Agg
Backend now changed to Cairo in tconfig object
writing file
reloading from mplrc_copy.conf
Backend reloaded from file: Cairo
It should be Cairo
deleting mplrc_copy.conf
This one is OK.
--------------------------------------------------------------------------------
creating RecursiveConfManager with no_mplrc.conf, which does not exist
calling RecursiveConfigManagers write() method
Here are the contents of no_mplrc.conf:I might have expected to see the MPLConfig defaults
Nope. The point is that a top-level file may well start empty,
without even an 'include' statement at all, and as the user changes
things (via the cmd line or edit_traits()), ONLY those changes will be
written in. This way, users don't carry a lot of declaration of
internal defaults that may potentially change as MPL evolves; this
minimizes the chances for config errors appearing in the future when
they upgrade.
Backend now changed to: Cairo
calling RecursiveConfigManagers write() method
Here are the new contents of no_mplrc.conf:in this test, dsd finds that no_mplrc.conf is empty after both writes
I suggest that tconfig should either write to the file, or raise an
error when the file does not exist
removing no_mplrc.conf
Fixed. See note on file creation at end.
------------------------------------------------------------------------
moving mplrc.conf to mplrc.conf.off
copying mplrc2.conf to mplrc2_copy.conf
loading config from mplrc2_copy.conf, which includes mplrc.conf-
but mplrc.conf does not exist
here are the contents of mplrc2_copy.conf, as loaded# A hierarchical configuration
include = 'mplrc.conf'Backend now changed to: Cairo
writing to file
Here are the new contents of mplrc2_copy.conf:# A hierarchical configuration
include = 'mplrc.conf'I might have expected to see the backend.use here
maybe an error should be raised when a config file includes another
config file that does not exist
moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.conf
Fixed, now raises IOError.
--------------------------------------------------------------------------
I implemented this policy:
1. Creating a TConfigManager(FooConfig,'missingfile.conf') will work
fine, and 'missingfile.conf' will be created empty.
2. Creating TCM(C,'OKfile.conf') where OKfile.conf has
include = 'missingfile.conf'
conks out with IOError.
My rationale is that creating top-level empty files is a common and
reasonable need, but that having invalid include statements should
raise an error right away, so people know immediately that their files
have gone stale.
It seems to me that this system does everything John and I discussed
over the phone on Sat, and that others have mentioned here.
Basically, MPL could install at startup time a simple matplotlib.conf
file that reads:
# MPL config file. For configuration details, try exloring
# pylab.rc
# If you are using WX or IPython with -wthread, you can try
# pylab.rc.edit_traits()
# for a GUI.
# This file:
# /path/to/full/copy/of/mpl/internal/mpl.conf
# is an auto-generated file with the complete current internal defaults.
# Feel free to copy pieces you need from it if you prefer.
# Note that you can create hierarchies of config files by using
# include = '/path/to/base.conf'
# For more details on MPL's config system, see
# http://matplotlib.sf.net/great/information/page.html
### EOF
That's it. Exactly zero actual data in the default file, just some
information to get people going. This file will only grow what people
actually change, thus minimizing the chances for problems that pop
like dandelions as upgrades happen.
In addition, even users who don't run with WX* backends could always
just start ipython -wthread to tweak their config, save it, and then
go back to using whatever they normally work with in production. WX
would only be needed for the traits GUI to open, not for any of MPL
itself.
Comments, feedback?
Cheers,
f
On 7/24/07, Darren Dale <dd55@...143...> wrote:
On Tuesday 24 July 2007 1:34:47 pm Fernando Perez wrote:
> creating RecursiveConfManager with no_mplrc.conf, which does not exist
> calling RecursiveConfigManagers write() method
> Here are the contents of no_mplrc.conf:
>
>
> I might have expected to see the MPLConfig defaultsNope. The point is that a top-level file may well start empty,
without even an 'include' statement at all, and as the user changes
things (via the cmd line or edit_traits()), ONLY those changes will be
written in.
Ah! (Smacks self on forehead)
This way, users don't carry a lot of declaration of
internal defaults that may potentially change as MPL evolves; this
minimizes the chances for config errors appearing in the future when
they upgrade.> Backend now changed to: Cairo
> calling RecursiveConfigManagers write() method
> Here are the new contents of no_mplrc.conf:
>
>
> in this test, dsd finds that no_mplrc.conf is empty after both writes
> I suggest that tconfig should either write to the file, or raise an
> error when the file does not exist
> removing no_mplrc.confFixed. See note on file creation at end.
Great!
> ------------------------------------------------------------------------
>
> moving mplrc.conf to mplrc.conf.off
> copying mplrc2.conf to mplrc2_copy.conf
> loading config from mplrc2_copy.conf, which includes mplrc.conf-
> but mplrc.conf does not exist
> here are the contents of mplrc2_copy.conf, as loaded
>
> # A hierarchical configuration
> include = 'mplrc.conf'
>
> Backend now changed to: Cairo
> writing to file
> Here are the new contents of mplrc2_copy.conf:
>
> # A hierarchical configuration
> include = 'mplrc.conf'
>
> I might have expected to see the backend.use here
> maybe an error should be raised when a config file includes another
> config file that does not exist
> moving mplrc.conf.off to mplrc.conf, deleting mplrc2_copy.confFixed, now raises IOError.
Great!
I implemented this policy:
1. Creating a TConfigManager(FooConfig,'missingfile.conf') will work
fine, and 'missingfile.conf' will be created empty.2. Creating TCM(C,'OKfile.conf') where OKfile.conf has
include = 'missingfile.conf'
conks out with IOError.
My rationale is that creating top-level empty files is a common and
reasonable need, but that having invalid include statements should
raise an error right away, so people know immediately that their files
have gone stale.It seems to me that this system does everything John and I discussed
over the phone on Sat, and that others have mentioned here.
Basically, MPL could install at startup time a simple matplotlib.conf
file that reads:# MPL config file. For configuration details, try exloring
# pylab.rc
# If you are using WX or IPython with -wthread, you can try
# pylab.rc.edit_traits()
# for a GUI.
# This file:
# /path/to/full/copy/of/mpl/internal/mpl.conf
# is an auto-generated file with the complete current internal defaults.
# Feel free to copy pieces you need from it if you prefer.
# Note that you can create hierarchies of config files by using
# include = '/path/to/base.conf'
# For more details on MPL's config system, see
# http://matplotlib.sf.net/great/information/page.html### EOF
That's it. Exactly zero actual data in the default file, just some
information to get people going. This file will only grow what people
actually change, thus minimizing the chances for problems that pop
like dandelions as upgrades happen.In addition, even users who don't run with WX* backends could always
just start ipython -wthread to tweak their config, save it, and then
go back to using whatever they normally work with in production. WX
would only be needed for the traits GUI to open, not for any of MPL
itself.Comments, feedback?
Thank you for all you have already done, Fernando.
I tried adding a bogus key to mplrc.conf (top level, bogus = 1), and ran the
mpltest.py script from IPython. The result is posted at the end of this
message. Would it be possible to provide some more context for bad sections
or keys? Like the section in which the key is located, the line number, or a
list of acceptable keys for that section? I think it will be necessary for
the error to relay the absolute path and file that failed, especially with
nested configs. We could catch that error, and point to the default conf that
ships with matplotlib, but a little additional information from tconfig would
be helpful.
It might be nice to be able to deprecate keys as matplotlib or ipython
evolves. Even with our current system, when we give a helpful message that a
key is no longer valid, we will sometimes get questions on the mailing lists
asking how to fix the problem. Raising an error for unrecognized keys might
be too extreme. Maybe TConfig should have a raiseOnKeyError option, so that
bad values can be reported with a warning instead, and the end user can get
up and running without fixing it right away.
Darren
<class 'tconfig.TConfigInvalidKeyError'> Traceback (most recent call last)
/home/darren/src/ipython1/sandbox/tconfig/mpltest.py in <module>()
10
11 mconf = 'mplrc.conf'
---> 12 mplconf = TConfigManager(MPLConfig, mconf, filePriority=True)
13 mplconf.tconf.backend.use = 'Qt4Agg'
14 mplconf.write()
/home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self,
configClass, configFilename, filePriority)
539
540 if filePriority:
--> 541 self.tconf =
configClass(self.fconfCombined,monitor=monitor)
542 else:
543 # Push defaults onto file object
/home/darren/src/ipython1/sandbox/tconfig/tconfig.py in __init__(self, config,
parent, monitor)
369 invalid_scalars = cf_scalars - my_scalars
370 if invalid_scalars:
--> 371 raise TConfigInvalidKeyError("Invalid keys: %s" %
invalid_scalars)
372
373 # ... and sections
<class 'tconfig.TConfigInvalidKeyError'>: Invalid keys: set(['bogus'])
WARNING: Failure executing file: <mpltest.py>
On Tuesday 24 July 2007 5:49:27 pm Fernando Perez wrote:
On 7/24/07, Darren Dale <dd55@...143...> wrote:
Thank you for all you have already done, Fernando.
My pleasure. I hope this will be useful for all of us, and that we
can offer to users unified mechanisms for dealing with the various
pieces of the 'scientific python toolkit' puzzle.
I tried adding a bogus key to mplrc.conf (top level, bogus = 1), and ran the
mpltest.py script from IPython. The result is posted at the end of this
message. Would it be possible to provide some more context for bad sections
or keys? Like the section in which the key is located, the line number, or a
list of acceptable keys for that section? I think it will be necessary for
the error to relay the absolute path and file that failed, especially with
nested configs. We could catch that error, and point to the default conf that
ships with matplotlib, but a little additional information from tconfig would
be helpful.
I can't pull line number information from ConfigObj:
http://www.voidspace.org.uk/python/configobj.html#todo
(see last line), but now the exception message reads:
TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf'
Contains the following invalid keys: ['bogus']
The valid keys for this section are: ['maskedarray', 'datapath',
'numerix', 'timezone', 'toolbar', 'interactive']
and similarly for invalid sections. At least with the filename and
the list of bad/good values, people should be able to fend for
themselves. If not, let them use matlab
Please update and let me know what happens.
It might be nice to be able to deprecate keys as matplotlib or ipython
evolves. Even with our current system, when we give a helpful message that a
key is no longer valid, we will sometimes get questions on the mailing lists
asking how to fix the problem. Raising an error for unrecognized keys might
be too extreme. Maybe TConfig should have a raiseOnKeyError option, so that
bad values can be reported with a warning instead, and the end user can get
up and running without fixing it right away.
As I told John, you can already do that: when you deprecate a Key,
simply change it from
class Foo(TConfig):
somekey = T.Int
to
somekey = DeprecatedKey
where DeprecatedKey is a Trait you declare, whose handler/validator
provides the necessary information to the user, sends warnings, it can
even set the proper value in the new form of that information if it
makes sense, etc.
Use the Traits, Luke
Cheers,
f
On 7/24/07, Darren Dale <dd55@...143...> wrote:
[...]
> Would it be possible to provide some more context for bad
> sections or keys?
[...]
now the exception message reads:
TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf'
Contains the following invalid keys: ['bogus']
The valid keys for this section are: ['maskedarray', 'datapath',
'numerix', 'timezone', 'toolbar', 'interactive']and similarly for invalid sections. At least with the filename and
the list of bad/good values, people should be able to fend for
themselves. If not, let them use matlab
That should be plenty of information. One comment: if you load mplrc2.conf,
which includes an mplrc.conf with a bogus key, the error indicates the bad
key is in mplrc2.conf. Is that a concern?
Please update and let me know what happens.
> It might be nice to be able to deprecate keys
[...]
when you deprecate a Key, simply change it from
class Foo(TConfig):
somekey = T.Intto
somekey = DeprecatedKey
where DeprecatedKey is a Trait you declare, whose handler/validator
provides the necessary information to the user, sends warnings, it can
even set the proper value in the new form of that information if it
makes sense, etc.
Great!
> Raising an error for
> unrecognized keys might be too extreme. Maybe TConfig should have a
> raiseOnKeyError option, so that bad values can be reported with a warning
> instead, and the end user can get up and running without fixing it right
> away.
This seemed an important point to me at first. But with well-documented,
auto-generated examples, creating minimal examples or stubs in
users .matplotlib or .ipython dirs, and a good mechanism for key deprecation,
now I dont think it will be a big deal to raise errors on bad keys. It should
be extremely rare.
Darren
On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
On 7/24/07, Darren Dale <dd55@...143...> wrote:
which includes an mplrc.conf with a bogus key, the error indicates the bad
key is in mplrc2.conf. Is that a concern?
It may be a concern to you, I suppose
Kidding aside, it's not totally trivial to implement the other
solution, which is why I didn't do it (or at least I couldn't think of
a really simple way to do it). In a sense the message is at least
correct, in that it gives the correct origin for the problem, but
users will have to track the inclusion chain themselves.
I'm sure we'll find more issues with complicated recursive setups as
we use this for 'real', and in the process we might find a nice
solution for this as well. For now, it will stay as is (at least
until you send me a patch that fixes it
> Please update and let me know what happens.
>
> > It might be nice to be able to deprecate keys
[...]
> when you deprecate a Key, simply change it from
>
> class Foo(TConfig):
> somekey = T.Int
>
> to
>
> somekey = DeprecatedKey
>
> where DeprecatedKey is a Trait you declare, whose handler/validator
> provides the necessary information to the user, sends warnings, it can
> even set the proper value in the new form of that information if it
> makes sense, etc.Great!
Glad you're happy. Traits are a really cool system.
> > Raising an error for
> > unrecognized keys might be too extreme. Maybe TConfig should have a
> > raiseOnKeyError option, so that bad values can be reported with a warning
> > instead, and the end user can get up and running without fixing it right
> > away.This seemed an important point to me at first. But with well-documented,
auto-generated examples, creating minimal examples or stubs in
users .matplotlib or .ipython dirs, and a good mechanism for key deprecation,
now I dont think it will be a big deal to raise errors on bad keys. It should
be extremely rare.
OK.
I guess it's now up to you guys (a collective MPL-dev you) to decide
if you want to use this system or not. We'll slowly try to replace
the ipython config with this, which I'm sure will uncover yet a few
more problems. But overall I'm quite happy with what we've got, and
I think the system is flexible enough that we should be able to solve
whatever remains.
Thanks for all your feedback and patience with testing!
Cheers,
f
On 7/24/07, Darren Dale <dd55@...143...> wrote:
On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
>
> : mplrc2.conf,
>
> which includes an mplrc.conf with a bogus key, the error indicates the
> bad key is in mplrc2.conf. Is that a concern?It may be a concern to you, I suppose
Not so much. I just wanted to give thorough feedback (No, I'm not *trying* to
drive you crazy).
I guess it's now up to you guys (a collective MPL-dev you) to decide
if you want to use this system or not. We'll slowly try to replace
the ipython config with this, which I'm sure will uncover yet a few
more problems. But overall I'm quite happy with what we've got, and
I think the system is flexible enough that we should be able to solve
whatever remains.
I'll start working on an option in svn-mpl to turn the new system on and wrap
it in an rcParams-like object. Then maybe we can convince a few devs to try
using the new system for a while.
Darren
On Tuesday 24 July 2007 11:17:32 pm Fernando Perez wrote:
On 7/24/07, Darren Dale <dd55@...143...> wrote:
> On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
Not so much. I just wanted to give thorough feedback (No, I'm not *trying* to
drive you crazy).
Don't worry, the damage was done long ago
More seriously, I do appreciate the feedback. It was very good to
have someone at the other end checking/breaking things (as well as the
conversation with John, to clarify a minimum set of functionality that
could make us all happy).
> I guess it's now up to you guys (a collective MPL-dev you) to decide
> if you want to use this system or not. We'll slowly try to replace
> the ipython config with this, which I'm sure will uncover yet a few
> more problems. But overall I'm quite happy with what we've got, and
> I think the system is flexible enough that we should be able to solve
> whatever remains.I'll start working on an option in svn-mpl to turn the new system on and wrap
it in an rcParams-like object. Then maybe we can convince a few devs to try
using the new system for a while.
Yup. Let me know of anything you need.
Cheers,
f
On 7/25/07, Darren Dale <dd55@...143...> wrote:
Darren Dale wrote:
[...]
I'll start working on an option in svn-mpl to turn the new system on and wrap it in an rcParams-like object. Then maybe we can convince a few devs to try using the new system for a while.
I will be happy to take a look and try it out. It certainly sounds like a major improvement over the previous system.
Eric