|
From: Abraham S. <ab...@cn...> - 2004-08-22 03:43:45
|
I do like the idea, and I was actually going to suggest something
similiar earlier on, but thought it wise at the time not to rock the
boat too much.. I am currently using this technique for my own code and
it's working out extremely well. The biggest problem with this approach,
is that I'm guessing the average user doesn't want to trawl through
python code to change a setting, or worry why Matplotlib doesn't work
because of some strange error message.
Because of this, I think it might make the most sense to partition the
rc file. For common settings, keep the current RC format, but then allow
python code to be executed for other settings.
A simple approach for this might be to add in directives to the RC
language like:
@import('file.rc')
or
@import('file.py')
Depending on the file type (i.e. ends in 'rc' or ends in 'py'), the file
could be parsed properly (either executed with 'execfile' with a given
namespace, or operate on rcParams).
This could also support other features such as verbosity:
@verbose moderate
That said, I think the current syntax for adding widgets and connecting
them isn't too bad. I think it's worth experimenting with to see which
is easier to use.
Abe
John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
>>>>>>
>>>>>>
>
> Fernando> 2. From some of your syntax struggles, I'm starting to
> Fernando> wonder whether it would be best to turn the
> Fernando> .matplotlibrc file into a proper python one. I followed
> Fernando> the same approach with ipython of having a custom
> Fernando> syntax, and now I regret it. It appears easier
> Fernando> initially, but in the long term it's clunky (at least
> Fernando> for ipython). For ipython's next major revision, I plan
> Fernando> on dumping its own rc format and allowing users to
> Fernando> define their configuration using plain python syntax.
> Fernando> Just some thoughts.
>
>I had the same thought this morning - you start with a simple config
>file, key/value pairs, but as you add features you find yourself
>writing a little primitive mini-language. Why ham-string yourself,
>when you already have an elegant, simple, powerful language available
>- python!
>
>When I get some more time tomorrow I'll take a close look at Abraham's
>code, and whether it might make more sense to move this section, or
>the who rc file, into python. That Abraham was able to factor out /
>modularize most of the toolbar code will certainly pave the way.
>
>Abraham, had you given this approach any thought in the midst of your
>work?
>
>Thanks!
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
|