matplotlib-devel Mailing List for matplotlib (Page 539)

>>>>> "Ingo" =3D=3D Ingo L=FCtkebohle <ilu...@gm...> writes:
 Ingo> Hi, a patch to compile the agg2 subdir with gcc 3.4 is on
 Ingo> sourceforge.
 Ingo> Background: The stricter template member-access checks in
 Ingo> gcc 3.4 break compilation of some agg2 headers. The problem
 Ingo> occurs when a class derives from a templatized class and
 Ingo> access members of the base class. Previously, the name of
 Ingo> the member was sufficient. Now, access to members of the
 Ingo> base class has to be qualified with "this".
 Ingo> [I sent this mail earlier, with the patch attached, but it
 Ingo> never arrived. Maybe mailman didn't like the attachment.
 Ingo> Sorry of you get duplicates.].
Sorry for the patch troubles. matplotlib cvs has already upgraded to
agg22, which among other things is fixed to handle gcc 3.4. I don't
have access to gcc 3.4 currently, so am unable to test matplotlib
compilation with agg22 with that version.
Could you give it a try and let me know?
Thanks!
JDH

Hi,
a patch to compile the agg2 subdir with gcc 3.4 is on sourceforge.
Background: The stricter template member-access checks in gcc 3.4
break compilation of some agg2 headers. The problem occurs when a
class derives from a templatized class and access members of the base
class. Previously, the name of the member was sufficient. Now,
access to members of the base class has to be qualified with "this".
[I sent this mail earlier, with the patch attached, but it never
arrived. Maybe mailman didn't like the attachment. Sorry of you get
duplicates.].
Ingo

>>>>> "thane" == <th...@ma...> writes:
 thane> I've got an alpha version of a .NET backend up and running
 thane> for matplotlib (http://matplotlib.sourceforge.net/ ). It
 thane> was just intended to be "proof-of-concept" code, but it
 thane> works.
I'm certainly interested. I don't know a lot about .Net. Is your
backend an image backend or GUI one? If the latter, are you using agg
for rendering ala tkagg, gtkagg, etc, or native .Net drawing?
Inquiring minds want to know.
 thane> This back end is targeted for anyone using PythonNet (see
 thane> http://www.zope.org/Members/Brian/PythonNet/index_html ).
 thane> It should also be compatible with IronPython (see
 thane> http://ironpython.com/) once the standard libraries and
 thane> Numarray (or Numeric) are available for the IronPython
 thane> release.
 thane> If there is any interest, please respond to this post and
 thane> I'll go through the trouble of adding it to the project (at
 thane> this point I don't know how to do this, so any guidance
 thane> here would be appreciated).
The standard procedure for submitting a backend is to send it to the
dev list, where I and other matplotlib developers can take it for a
test drive and submit feedback.
I'd be happy to give it a try. If you have any extra instructions for
.Net dummies, please send them along with the code.
Cheers!
JDH
 
 thane> --Thane
 
 thane> Thane Plummer, Ph.D.
 thane> CEO Magna Capital, LLC
 thane> (520) 760-4957
 thane> (520) 405-2277 (cell)
 thane> <mailto:th...@ma...> th...@ma...
 thane> <http://www.magna-capital.com> www.magna-capital.com
 
 

I've got an alpha version of a .NET backend up and running for matplotlib
(http://matplotlib.sourceforge.net/ ). It was just intended to be
"proof-of-concept" code, but it works.
 
This back end is targeted for anyone using PythonNet (see
http://www.zope.org/Members/Brian/PythonNet/index_html ). It should also be
compatible with IronPython (see http://ironpython.com/) once the standard
libraries and Numarray (or Numeric) are available for the IronPython
release.
 
If there is any interest, please respond to this post and I'll go through
the trouble of adding it to the project (at this point I don't know how to
do this, so any guidance here would be appreciated).
 
--Thane
 
Thane Plummer, Ph.D.
CEO Magna Capital, LLC
(520) 760-4957
(520) 405-2277 (cell)
 <mailto:th...@ma...> th...@ma...
 <http://www.magna-capital.com> www.magna-capital.com 
 
 

On Sep 24, 2004, at 10:59 AM, John Hunter wrote:
>
> The other core features that would be nice to have but aren't
> absolutely critical are polar and contour. I believe the stsci folks
> are working on contour.
>
Off and on, but indeed we are working on implementing contour plots.
Perry

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> My argument is that most other software I've looked at does
 Steve> this and it seems to work OK. I guess the reasons are that
 Steve> - it makes software packages smaller - you only need to
 Steve> directly download one copy of a package and do not
 Steve> indirectly download multiple copies of the same package. -
 Steve> you can end up with multiple versions of a package. And
 Steve> later you may try to recall - which package x did I use to
 Steve> install package y? - the software package that includes
 Steve> other packages needs to make sure it keeps up to date with
 Steve> with the included packages and does not install old
 Steve> versions.
Hi Steve,
Those are reasonable arguments. I'm still convinced that it is better
to err on the side of simplifying the install, though. matplotlib has
been distributing some of it's prereqs for some time (agg, pyparsing)
and not others (Numeric/numarray, freetype, libpng). I try to balance
the likelihood the user already has the package on their system, the
additional ease/complexity of installation and coding, and package
size. On balance, I decided to add pytz and dateutil to the
matplotlib src distro - I won't however, overwrite existing installs.
In the past we've included things (fontutils, ttfquery) that were
eventually removed because we found or wrote better replacements. So
the matplotlib package size tends to fluctuate up and down a bit.
Currently, with src, fonts, icons, examples, example data, and add-on
packages, the src dist comes to 1.6M. I can live with that.
 Steve> As a way to encourage more users how about working towards
 Steve> moving from the development status of version 0.62.4 "4 -
 Steve> Beta" to 1.0.0 "5 - Production/Stable". What's the
 Steve> criteria for this step? My understanding is that it does
 Steve> not mean that all desired features are implemented or
 Steve> complete, it just means that the software is stable, and
 Steve> matplotlib seems to be pretty stable already.
I'm amenable. Do you know of instances where people aren't using
matplotlib due to it's version number or development status flag?
My working plan is to be mostly 2D feature complete for 1.0, but I am
not wed to this. As you say, 1.0 really just implies some stability
rather than feature set.
The only thing off the top of my head that must be added before 1.0 is
a Users Guide - I should be done with this already, but alas...
Should be done in a month (I said that last month) I also think it
would also be nice to have a more streamlined, sophisticated configure
process.
The other core features that would be nice to have but aren't
absolutely critical are polar and contour. I believe the stsci folks
are working on contour.
As for stability, there will probably be a significant refactoring of
the renderer drawing API at some point. But I don't think this
precludes a 1.0 release. As long as the matlab interface and OO
Figure/Axes/Text/Line/Patch interface is stable, and it largely is
discussed on the user's list), then I don't think it would break any
existing code to refactor the drawing model down the road. As far as
I know, noone is directly using the renderer API, and I've never
advertised it.
JDH

>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:
 Patrik> Here's a proposed patch for the caching problem in
 Patrik> text.py. (I'm sending it before someone actually adds
 Patrik> matplotlib.text.Text.cached = {} to, e.g.,
 Patrik> matlab.close(). Oh, the horror :-)
What happened when you put it there?
It's not clear to me where to me where that misplaced zero is coming
from. Since the two figures are identical in size, I would think the
cached location of '0' from the first iteration of the loop would be
suitable for the second iteration. Do you understand how this is
failing?
The main reason for the cache was for efficiency in animated plots.
Eg, if you are just updating the data in a plot and then redrawing,
you don't want to do all the number crunching for text layout. With
rotated text and matrix operations to get the layout right, this can
get expensive.
I read over your patch. I wonder if a simpler and cleaner solution
might just be to move the cached into the __init__ method. Ie, make
it instance specific. This would still provide the cache efficiency
for animated plots, but should fix the problem you encountered.
It might also be less mind-bending than the solution you posted, at
least at this hour of the morning :-)
But I *would* like to understand how the current situation is
failing. I note that it does not occur if you replace figure(1) with
figure(i+1).
JDH

Here's a proposed patch for the caching problem in text.py.
(I'm sending it before someone actually adds
matplotlib.text.Text.cached = {}
to, e.g., matlab.close(). Oh, the horror :-)
-- 
Patrik

Hi there,
matplotlib.text.Text._get_layout(self, renderer) caches
its return value in the dictionary matplotlib.text.Text.cached.
Since it is never emptied, it causes problems when one
creates many figures.
Below, t0.png is ok but t1.png has the vertical tick label 0 in the
wrong place.
import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *
y = [[100, 250], [10, 25]]
for i in range(2):
 figure(1)
 bar([0,1], y[i])
 savefig('t%d.png' % i)
 # Uncomment to fix
 #matplotlib.text.Text.cached = {}
 close('all')
-- 
Patrik

John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>> 
>>>>>>
>
> Steve> My view is that a software package should not distribute
> Steve> and install its own dependencies. I think matplotlib
> Steve> should have a list of dependencies (Python 2.2+, Numeric or
> Steve> numarray, ...) which it requires before it attempts an
> Steve> install, and a list of optional dependencies (pytz,
> Steve> dateutil, ...) which matplotlib supports if it finds they
> Steve> are already installed.
>
>What's your argument for this?
>
>My motivation to include them is mainly to simplify the install
>process, to have some control over versioning, and to simplify the
>coding process. 
>
I agree with JDH on this one. Including extra pure-Python packages is 
not likely to cause (m)any problems:
1) on systems where people do lots of "python setup.py install" the 
definitive list of installed packages is the contents of site-packages
2) on systems with real package managers (e.g. Debian), this is for the 
package maintainer to worry about. those extra packages should be made 
package-level dependencies and not in the matplotlib.deb itself. (this 
assumes people on these systems are using the package manager. if not, 
see point #1)
3) on Windows, you want to double click something that just works.
(In fact, by this reasoning, there's nothing against including mixed 
C/Python packages, either.)

On Tue, 2004年09月21日 at 19:44, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> My view is that a software package should not distribute
> Steve> and install its own dependencies. I think matplotlib
> Steve> should have a list of dependencies (Python 2.2+, Numeric or
> Steve> numarray, ...) which it requires before it attempts an
> Steve> install, and a list of optional dependencies (pytz,
> Steve> dateutil, ...) which matplotlib supports if it finds they
> Steve> are already installed.
> 
> What's your argument for this?
My argument is that most other software I've looked at does this and it
seems to work OK. I guess the reasons are that
- it makes software packages smaller
- you only need to directly download one copy of a package and do not
indirectly download multiple copies of the same package.
- you can end up with multiple versions of a package. And later you may
try to recall - which package x did I use to install package y?
- the software package that includes other packages needs to make sure
it keeps up to date with with the included packages and does not install
old versions.
> My motivation to include them is mainly to simplify the install
> process, to have some control over versioning, and to simplify the
> coding process. Since these are pure python packages, they present no
Yes, this is an advantage of including everything, and a disadvantage
for minimal packages.
> Does your opinion change for the win32 installer? In that case, we
> also include freetype, libpng, zlib. I guarantee the numbers of win32
> users would drop significantly if they had to install these extra
> packages. Neither dateutil nor pytz distribute a win32 installer.
> dateutil doesn't include a zip file (only a tar.bz file). So win32
> users would first have to get bunzip2, and then tar, figure out how to
> use them, install, etc, just to get matplotlib date support.
Win32 could be a special case.
As a way to encourage more users how about working towards moving from
the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 -
Production/Stable".
What's the criteria for this step?
My understanding is that it does not mean that all desired features are
implemented or complete, it just means that the software is stable, and
matplotlib seems to be pretty stable already.
Regards,
Steve

On Tuesday 21 September 2004 11:54 am, Steve Chaplin wrote:
> My view is that a software package should not distribute and install its
> own dependencies.
> I think matplotlib should have a list of dependencies (Python 2.2+,
> Numeric or numarray, ...) which it requires before it attempts an
> install, and a list of optional dependencies (pytz, dateutil, ...) which
> matplotlib supports if it finds they are already installed.
I second that.
-- 
Darren Dale

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> My view is that a software package should not distribute
 Steve> and install its own dependencies. I think matplotlib
 Steve> should have a list of dependencies (Python 2.2+, Numeric or
 Steve> numarray, ...) which it requires before it attempts an
 Steve> install, and a list of optional dependencies (pytz,
 Steve> dateutil, ...) which matplotlib supports if it finds they
 Steve> are already installed.
What's your argument for this?
My motivation to include them is mainly to simplify the install
process, to have some control over versioning, and to simplify the
coding process. Since these are pure python packages, they present no
extra installation overhead for matplotlib and the only downside I see
is potential package bloat. Both of these packages combined add 200k
to the src distro. The coding burden is reduced, if for example I
know pytz is included, because I don't have to do a lot of conditional
stuff throughout the code where that module is used.
Does your opinion change for the win32 installer? In that case, we
also include freetype, libpng, zlib. I guarantee the numbers of win32
users would drop significantly if they had to install these extra
packages. Neither dateutil nor pytz distribute a win32 installer.
dateutil doesn't include a zip file (only a tar.bz file). So win32
users would first have to get bunzip2, and then tar, figure out how to
use them, install, etc, just to get matplotlib date support.
Basically, my goal is to maximize the likelihood that someone can use
matplotlib even if they haven't RTFM. I wish they would read the
install instructions and dependencies, but I think that is only about
half of the users. If we can set it up so that most things work out
of the box on a standard python setup - and I think having
Numeric/numarray) is fairly standard for most potential matplotlib
users. 
On a related note, Todd just added a fix in CVS that autodetects
numerix at build time and builds in Numeric and/or numarray. It would
probably be a good idea to have an rc template and write the actual rc
file depending on what the autodetect finds in setup.py. Eg, if setup
finds Tkinter and numarray but not pygtk and Numeric, there's not much
sense in using the default backend : GTKAgg and numerix : Numeric in
rc. Paul did something like this for the license, so that the license
file was automatically built with the correct version number at build
time.
JDH

My view is that a software package should not distribute and install its
own dependencies. 
I think matplotlib should have a list of dependencies (Python 2.2+,
Numeric or numarray, ...) which it requires before it attempts an
install, and a list of optional dependencies (pytz, dateutil, ...) which
matplotlib supports if it finds they are already installed.
Regards,
Steve

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> Should I assume that the installed packages would have the
 Paul> same structure, i.e. lib/python2.3/site-packages/matplotlib/
 Paul> ? If yes, then I see no problem with this proposal.
Yes, the install paths would be unaffected.
JDH

John Hunter wrote:
>Many new users have been bitten by trying to run matplotlib from the
>matplotlib src dir, only to get an inscrutable error about not being
>able to find some extension code, as described in this FAQ
>http://matplotlib.sourceforge.net/faq.html#WRONGDIR.
>
>Recently, I've added pytz and dateutil for improved timezone and date
>ticking to the src distro. I want to conditionally install these
>packages with matplotlib, only if the user hasn't installed them
>already. So in setup.py, I do for example
>
>try: import dateutil
>except ImportError:
> packages.append('dateutil')
>
>
>But I was bitten by the same bug. Because dateutil was in the
>matplotlib root dir, it was imported successfully and not installed.
>
>My proposal is to move all the python library code into a lib subdir,
>which currently would look like
>
> lib\matplotlib
> lib\pytz
> lib\dateutil
>
>and use package_dir = {'': 'lib'} in setup.py, which would fix both
>problems.
>
>Of course, I'll have to submit an admin request to sourceforge just to
>get the old dirs purged. Sure would be nice if CVS supported basic
>rename and delete operations on directories.
>
>Comments, suggestions, objections...
> 
>
Should I assume that the installed packages would have the same 
structure, i.e. lib/python2.3/site-packages/matplotlib/ ? If yes, then I 
see no problem with this proposal.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Many new users have been bitten by trying to run matplotlib from the
matplotlib src dir, only to get an inscrutable error about not being
able to find some extension code, as described in this FAQ
http://matplotlib.sourceforge.net/faq.html#WRONGDIR.
Recently, I've added pytz and dateutil for improved timezone and date
ticking to the src distro. I want to conditionally install these
packages with matplotlib, only if the user hasn't installed them
already. So in setup.py, I do for example
try: import dateutil
except ImportError:
 packages.append('dateutil')
But I was bitten by the same bug. Because dateutil was in the
matplotlib root dir, it was imported successfully and not installed.
My proposal is to move all the python library code into a lib subdir,
which currently would look like
 lib\matplotlib
 lib\pytz
 lib\dateutil
and use package_dir = {'': 'lib'} in setup.py, which would fix both
problems.
Of course, I'll have to submit an admin request to sourceforge just to
get the old dirs purged. Sure would be nice if CVS supported basic
rename and delete operations on directories.
Comments, suggestions, objections...
JDH

Hi,
I think I might have noticed an off by one bug in the pcolor and
pcolor_classic functions. To replicate the problem:
from matplotlib.matlab import *
import Numeric
pcolor(Numeric.transpose(rand(2,2)))
** Note that although this is a 2x2 matrix the pcolor plot is rendered
 with only 1 square. This problem scales. The dimensions of the pcolor
 plots are always 1 less than they should be.
Changing line 1306 in axes.py (I'm running the debian package ver. 0.61.0-2)
from:
 X, Y = meshgrid(arange(numCols), arange(numRows) )
to:
 X, Y = meshgrid(arange(numCols+1), arange(numRows+1) )
And I think similar change can fix pcolor_classic too.
This fixes the off-by-one problem when plotting arrays. I haven't
thoroughly tested this, but I think it works in all cases.
 --chris.
PS. Thanks for the nice work on matplotlib.
----------------------
Christopher Hart
Caltech Biology

In the generated documentation ( the doc string ) for scatter,
'octagon' is mispelled 'octogon'. 
S
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Thanks for the tip on variable expansion. I'll add it in
 Abraham> to my current code.
Hi Abraham,
Just wanted to let you know I haven't dropped off the face of the
planet. With SciPy looming and other deadlines, I haven't had a
chance to look into your code in any detail. I'll be away all of next
week, so it will be some time until I get a chance to take a look.
Keep plugging away (pun intended) and hopefully we can put together
something nice in the near term. I think your hybrid solution of
using a plain text key/val pair format for rc, and user customizable
python for toolbar config, is a good one.
JDH

Abraham Schneider wrote:
> I completely agree. I recently changed the code to allow a path to be 
> specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax 
> .. something to think about. However, if people have a .matplotlibrc 
> file in their home directory, it should make it so people aren't mucking 
> up things with the plugins.. I'll have to check the behavior of 
> find_module to see what it does with '~' and such.
You can expand the user-given string by doing:
user_dirlist = os.path.expanduser(os.path.expandvars(user_path)).split(':')
This gives you a list of directories to search, with user ~names and 
$VARIABLES expanded out. This approach worked fine for mayavi.
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

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!
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

Fernando Perez wrote:
>
>
> 1. I think plugin support is a fantastic idea, but I hope it can be 
> made user-extensible in local paths. I recently modified mayavi 
> (available in current CVS) precisely in this manner, and I think it's 
> a very useful thing. In lab settings where users are not allowed to 
> write to system directories, it becomes very important that they can 
> add their own plugins in local paths. This also allows you to keep 
> your personal extensions alive as matplotlib versions are upgraded, 
> since your directories are untouched.
>
> What I did for mayavi was to add a search-path option to mayavi, made 
> of colon-separated dirs with ~user/$VAR support. Any such dir gets 
> added to mayavi's search path for user-defined filters and modules 
> (the equivalent of plugins), and you can load a user module just like 
> you can load a builtin:
>
> load_module('Glyphs') -> loads mayavi's Glyphs module
> load_module('User.Glyphs') -> loads a user-defined Glyphs module from 
> the search path.
>
> I think it's important that it's a _path_ and not a single directory, 
> because this allows a research group to maintain shared extensions 
> suited for their purposes, and individual users to add personal 
> modifications which don't fit group projects.
I completely agree. I recently changed the code to allow a path to be 
specified (':' deliminated). I hadn't thought of allowing '$VAR' syntax 
.. something to think about. However, if people have a .matplotlibrc 
file in their home directory, it should make it so people aren't mucking 
up things with the plugins.. I'll have to check the behavior of 
find_module to see what it does with '~' and such.
I like the idea of 'load_module'. Currently all the plugins in the 
directories are loaded automatically. There is a certain nicety, though, 
to automatically having it load all the plugins found in a particular 
directory. Less cumbersome for most users.
Abe

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