On 7/24/07, Darren Dale <[EMAIL PROTECTED]> wrote: > On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
> :) 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? 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 ------------------------------------------------------------------------- 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
