more on plugins/toolbar

2. From some of your syntax struggles, I'm starting to

    > wonder whether it would be best to turn the
    > .matplotlibrc file into a proper python one. I followed
    > the same approach with ipython of having a custom
    > syntax, and now I regret it. It appears easier
    > initially, but in the long term it's clunky (at least
    > for ipython). For ipython's next major revision, I plan
    > on dumping its own rc format and allowing users to
    > define their configuration using plain python syntax.
    > 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

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 <Fernando.Perez@...76...> writes:
           
   > 2. From some of your syntax struggles, I'm starting to
   > wonder whether it would be best to turn the
   > .matplotlibrc file into a proper python one. I followed
   > the same approach with ipython of having a custom
   > syntax, and now I regret it. It appears easier
   > initially, but in the long term it's clunky (at least
   > for ipython). For ipython's next major revision, I plan
   > on dumping its own rc format and allowing users to
   > define their configuration using plain python syntax.
   > 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:

"Fernando" == Fernando Perez <Fernando.Perez@...76...> writes:

    > 2. From some of your syntax struggles, I'm starting to
    > wonder whether it would be best to turn the
    > .matplotlibrc file into a proper python one. I followed
    > the same approach with ipython of having a custom
    > syntax, and now I regret it. It appears easier
    > initially, but in the long term it's clunky (at least
    > for ipython). For ipython's next major revision, I plan
    > on dumping its own rc format and allowing users to
    > define their configuration using plain python syntax.
    > 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!

There are a few technical issues with this problem, some of which I've partly thought about. This will be one of my first things to do once I'm done with matplotlib support in ipython, as part of the rewrite. Perhaps we could share some of the work for this problem with a light module for handling python config files with proper namespace control and recursive inclusion (important for handling global defaults modified by local project fine-tuning).

Best,

f

Abraham Schneider wrote:

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).

-1, too complicated to code and maintain, IMHO. And @foo looks poised to become valid python syntax, in case you've missed the recent firestorms on c.l.py and python-dev.

In my view, matplotlib (and similarly ipython) are already tools for people coding in python to begin with. So they can deal with python syntax, otherwise they wouldn't be using them. Simplified syntaxes may make sense for configuring end-user programs, but for that we already have ConfigParser in the stdlib. We have better things to do than reinventing half-working implementations of toy languages, and users will always end up needing an if statement, a looping construct, a system access function, etc. Might as well just give them all of python and be done with it, I think.

The approach I have in mind for ipython is simply making sure that any exceptions generated during the execution of this file are presented very clearly to the user, with full source details and a clear message wrapping them going to stderr. This will indicate not only the exception but the fact that it is occurring in the user's config file and that ipython (or matplotlib) can't proceed further until this is fixed. IPython comes with a better exception formatter than the default (ultraTB, essentially a console port of cgitb); matplotlib is welcome to use it.

Best,

f