> 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 scheme: import > MPLConfig in setup.py, set the attributes, dump to a default config file.
My thought for IPython is to have defaults set in the traited config class itself so you wouldn't even have to do the second step. Just import MPLConfig and dump to a file. I too think this is one of the really nice benefits of this approach. Generating the default config file for IPython1 was becoming a real problem. > [...] > > In summary, I'm fairly happy with the results, and I think the benefit > > is enough to convince me of falling in the embrace of the gods of > > Traits. It seems John is going for Traits as well, so perhaps we can > > use this little config setup across our systems, and even make it > > something that others use in the future. I think there's value for > > end users in having common, uniform configuration systems across the > > various parts of the scientific python 'ecosystem'. > > I agree. It looks really elegant. What about the circular dependencies you > mentioned in a previous email, is that still a potential problem? The circular dependency problem goes away in the following way. The config files and config objects will only consist of basic types (int, strings, float, lists, dicts, etc) - not executable python code. If you need to specify python code (the name of a class that implements some behavior for example) that would be specified as a string. During the initial parts of the configuration process, that would remain a string, thus avoiding the circular dependency problem. Only after it is safe to execute/import, would the string be exec'd. > Darren > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
