On 7/24/07, Darren Dale <dd...@co...> 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