Re: [matplotlib-devel] more on plugins/toolbar

[Fernando P. <Fer...@co...>]

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