matplotlib-devel Mailing List for matplotlib (Page 2)

OK, I created a test for numpy to isolate an issue: 
http://scipy.org/scipy/numpy/ticket/629
I think setting MPL's behavior to repr() is good, though. John, I see 
you did that r4745 -- thanks.
-Andrew
Fernando Perez wrote:
> On Dec 15, 2007 2:52 PM, Andrew Straw <str...@as...> wrote:
>> Hang on a minute, it looks like numpy.float64.__repr__() itself isn't
>> reproducing all significant digits... I'm writing up a test now and will
>> move this to the numpy list. I'm not sure how much is MPL and how much
>> is numpy at this point.
> 
> you may want to ping also at #scipy on irc.freenode.net, where the
> sprint participants are all hanging out.
> 
> cheers,
> 
> f

On Dec 15, 2007 2:52 PM, Andrew Straw <str...@as...> wrote:
> Hang on a minute, it looks like numpy.float64.__repr__() itself isn't
> reproducing all significant digits... I'm writing up a test now and will
> move this to the numpy list. I'm not sure how much is MPL and how much
> is numpy at this point.
you may want to ping also at #scipy on irc.freenode.net, where the
sprint participants are all hanging out.
cheers,
f

Hang on a minute, it looks like numpy.float64.__repr__() itself isn't 
reproducing all significant digits... I'm writing up a test now and will 
move this to the numpy list. I'm not sure how much is MPL and how much 
is numpy at this point.
Trying to make a roundtrip through a .csv file not loose precision,
Andrew
John Hunter wrote:
> On Dec 15, 2007 3:13 PM, Andrew Straw <str...@as...> wrote:
> 
>> mlab.defaultformatd sets the default float formatter for rec2csv() to be
>> something that doesn't keep the full representation of a floating point
>> number. Obviously, I can pass in my own formatd argument to rec2csv(),
>> but I wonder if there's any reason why defaultformatd shouldn't use
>> repr() for numpy.float32 and numpy.float64?
>> 
>
> I'll be happy to make repr the default. I was using %g because I
> mistakenly though this provided the appropriate number of significant
> digits. I changed this to %r in the csvformat_factory in svn.
>
> JDJ
> 

On Dec 15, 2007 3:13 PM, Andrew Straw <str...@as...> wrote:
> mlab.defaultformatd sets the default float formatter for rec2csv() to be
> something that doesn't keep the full representation of a floating point
> number. Obviously, I can pass in my own formatd argument to rec2csv(),
> but I wonder if there's any reason why defaultformatd shouldn't use
> repr() for numpy.float32 and numpy.float64?
I'll be happy to make repr the default. I was using %g because I
mistakenly though this provided the appropriate number of significant
digits. I changed this to %r in the csvformat_factory in svn.
JDJ

On Dec 15, 2007 2:13 PM, Andrew Straw <str...@as...> wrote:
> Hi,
>
> mlab.defaultformatd sets the default float formatter for rec2csv() to be
> something that doesn't keep the full representation of a floating point
> number. Obviously, I can pass in my own formatd argument to rec2csv(),
> but I wonder if there's any reason why defaultformatd shouldn't use
> repr() for numpy.float32 and numpy.float64?
+1 for repr() in general as the default output method, as it is
supposed (though not guaranteed) in general to be more faithful to the
original object.
cheers,
f

Hi,
mlab.defaultformatd sets the default float formatter for rec2csv() to be 
something that doesn't keep the full representation of a floating point 
number. Obviously, I can pass in my own formatd argument to rec2csv(), 
but I wonder if there's any reason why defaultformatd shouldn't use 
repr() for numpy.float32 and numpy.float64?

Gael Varoquaux wrote:
> Guys, I agree with all this. It's not about the theory, but about the
> user experience. The user just types along, and doesn't read books and
> manuals. A least the average user. And we want to make it as easy as
> possible for her.
Yes, we all like that.
Which is why it was decided that __repr_ was the better default for 
display at the command line. See my example, too many questions along 
the lines of "python has a bug!" -- I'm guessing a very large fraction 
of those were about FP issues -- poorly understood my most newbies.
I think it is clearly the best choice for things like a single floating 
point number, but for far more complex objects? who knows. As an 
example, look at the default behavior of numpy arrays:
 >>> a = numpy.ones((3,3))
 >>> a
array([[ 1., 1., 1.],
 [ 1., 1., 1.],
 [ 1., 1., 1.]])
Classic __repr__.
but:
 >>> a = numpy.ones((1000,1000))
 >>> a
array([[ 1., 1., 1., ..., 1., 1., 1.],
 [ 1., 1., 1., ..., 1., 1., 1.],
 [ 1., 1., 1., ..., 1., 1., 1.],
 ...,
 [ 1., 1., 1., ..., 1., 1., 1.],
 [ 1., 1., 1., ..., 1., 1., 1.],
 [ 1., 1., 1., ..., 1., 1., 1.]])
no longer follows the __repr__ rules. I think that's an excellent choice 
-- it's really never useful to spew something that large to the screen.
Given this discussion, what are you currently proposing?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Fernando Perez wrote:
> For a while I've toyed with the idea of adding an option to ipython so
> the output prompts could use str() instead of repr(), so users who
> *deliberately* want to switch, aware of the potential conflicts, do
> so.
+1
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Michael Droettboom wrote:
> Manuel Metz wrote:
>> Hi,
>> I figured out a bug in the FancyArrow class (sorry, I didn't track it 
>> down, yet). Might be related to my strange axes limits ?
>>
>> Please have a look at the attached example. As you can see, in the 
>> lower panel the head is not rendered correctly.
> 
> It appears to be stretching the arrow to fit in the rectangle defined by 
> its points. Doesn't seem to be the right transformation. However, it 
> looks as if it's been that way for a long time. Was this working for 
> you at one time and then it broke, or is this your first attempt with 
> FancyArrow? None of the matplotlib examples use FancyArrow. Maybe it's 
> deprecated...?
No, it did not work before. I first wanted to use pylab.arrow, but then 
the head of the arrow was very, very long streched -> so I switched to 
FancyArrow, because it allowed me to draw a "nice & normal" arrow-head 
-- until I decided to not draw it parallel to the coordinate axis :-(
>> BTW: When building matplotlib I get a lot of warnings:
>> [.....]
>> src/image.cpp: In member function ‘Py::Object Image::buffer_rgba(const 
>> Py::Tuple&)’:
>> src/image.cpp:266: warning: deprecated conversion from string constant 
>> to ‘char*’
>> [.....]
> 
> If you're using Python < 2.5 in conjunction with a recent gcc, that 
> would be expected, but most likely benign. Python 2.5 changed the type 
> of those arguments to "const char *" to avoid this warning.
Ah, I see - thanks for the info.
Cheers,
 Manuel

Manuel Metz wrote:
> Hi,
> I figured out a bug in the FancyArrow class (sorry, I didn't track it 
> down, yet). Might be related to my strange axes limits ?
> 
> Please have a look at the attached example. As you can see, in the lower 
> panel the head is not rendered correctly.
It appears to be stretching the arrow to fit in the rectangle defined by 
its points. Doesn't seem to be the right transformation. However, it 
looks as if it's been that way for a long time. Was this working for 
you at one time and then it broke, or is this your first attempt with 
FancyArrow? None of the matplotlib examples use FancyArrow. Maybe it's 
deprecated...?
> BTW: When building matplotlib I get a lot of warnings:
> [.....]
> src/image.cpp: In member function ‘Py::Object Image::buffer_rgba(const 
> Py::Tuple&)’:
> src/image.cpp:266: warning: deprecated conversion from string constant 
> to ‘char*’
> [.....]
If you're using Python < 2.5 in conjunction with a recent gcc, that 
would be expected, but most likely benign. Python 2.5 changed the type 
of those arguments to "const char *" to avoid this warning.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thursday 13 December 2007 11:07:57 am John Hunter wrote:
> I moved the tools in mlab that did optional imports (the rec2gtk and
> rec2excel functions and their dependencies) out of mlab into
> toolkits.gtktools and toolkits.exceltools. As Michael noted, these
> imports can be expensive for users with gtk on their system and do not
> belong in mlab. In some cases, eg logged in over a dumb terminal with
> no x11 but where gtk is present, they also trigger text warnings or
> errors from gtk, so are a nuisance. I thought it was worth cleaning
> this up for the bugfix release.
>
> If you get a minute to test before the release, that would help -- the
> excel part requires pyExcelerator, which is pure python
> http://sourceforge.net/projects/pyexcelerator
>
> import gtk
> import matplotlib.mlab as mlab
> import matplotlib.toolkits.gtktools as gtktools
> import matplotlib.toolkits.exceltools as exceltools
>
> r = mlab.csv2rec('test.csv', checkrows=0)
>
> formatd = dict(
> weight = mlab.FormatFloat(2),
> change = mlab.FormatPercent(2),
> cost = mlab.FormatThousands(2),
> )
>
>
> exceltools.rec2excel(r, 'test.xls', formatd=formatd)
> mlab.rec2csv(r, 'test.csv', formatd=formatd)
>
>
>
> scroll = gtktools.rec2gtk(r, formatd=formatd, autowin=False)
> win = gtk.Window()
> win.set_size_request(600,800)
> win.add(scroll)
> win.show_all()
> gtk.main()
I just ran this on 64-bit linux and didnt see any problems. I do have an issue 
with pygtk on my system, but I dont think it is related to mpl:
/usr/lib64/python2.5/site-packages/gtk-2.0/gtk/__init__.py:69: Warning: 
ignoring sys.argv: it must be a list of strings
 _gtk.init_check()

Hi,
I figured out a bug in the FancyArrow class (sorry, I didn't track it 
down, yet). Might be related to my strange axes limits ?
Please have a look at the attached example. As you can see, in the lower 
panel the head is not rendered correctly.
I used the lates svn, revision 4730.
Manuel
BTW: When building matplotlib I get a lot of warnings:
[.....]
src/image.cpp: In member function ‘Py::Object Image::buffer_rgba(const 
Py::Tuple&)’:
src/image.cpp:266: warning: deprecated conversion from string constant 
to ‘char*’
[.....]

On Thu, Dec 13, 2007 at 03:14:23PM -0800, Christopher Barker wrote:
> I'm not up on the details of this specific issue, but in general, the 
> idea that:
> __repr__ is precise and complete
> __str__ is pretty and readable
> is a good one.
Guys, I agree with all this. It's not about the theory, but about the
user experience. The user just types along, and doesn't read books and
manuals. A least the average user. And we want to make it as easy as
possible for her.
And actually, it feels nice when I can pick up something new and be
efficient quickly. And if on top of that I discover that I can keep
learning and improving for a long time and discover the hidden power of
what I am using, that's great and I am happy.
Cheers,
Gaël

On Dec 13, 2007 4:14 PM, Christopher Barker <Chr...@no...> wrote:
> I'm not up on the details of this specific issue, but in general, the
> idea that:
>
> __repr__ is precise and complete
> __str__ is pretty and readable
>
> is a good one
+1
For a while I've toyed with the idea of adding an option to ipython so
the output prompts could use str() instead of repr(), so users who
*deliberately* want to switch, aware of the potential conflicts, do
so.
It's easy and I'm about to get on a plane, so I might code it in if I can.
Cheers,
f

Gael Varoquaux wrote:
>> x == eval(repr(x))
> 
>> That is true for many of the builtin data types of the language.
And the really the whole point of having __repr__, in addition to __str__
> I totally agree. However if a user types:
> pylab.rcParams
> in IPython, or the Python interpreter, she gets the repr, AFAIK.
That's a python interpreter change a couple versions back. One of the 
reasons for it is:
 >>> str(a)
'0.1'
 >>> str(b)
'0.1'
 >>> a == b
False
huh? why false???
 >>> a
0.10000000000000002
 >>> b
0.10000000000000001
 >>>
Ah -- now I see. It was felt that this was a case where being as precise 
as possible with the default output was a good idea.
If you want the pretty version, use print:
 >>> print a, b
0.1 0.1
I'm not up on the details of this specific issue, but in general, the 
idea that:
__repr__ is precise and complete
__str__ is pretty and readable
is a good one.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

John Hunter wrote:
> Do we need namespace packages in toolkits? I recently added gtktools
> and exceltools to toolkits, and got a very hard to debug error:
> 
> In [1]: import matplotlib
> 
> In [2]: matplotlib.__file__
> Out[2]: '/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.pyc'
> 
> In [3]: matplotlib.rcParams['axes.axisbelow']
> Out[3]: False
> 
> In [4]: import matplotlib.toolkits.gtktools
> 
> In [5]: matplotlib.__file__
> Out[5]: '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/matplotlib/__init__.pyc'
> 
> In [6]: matplotlib.rcParams['axes.axisbelow']
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
> KeyError: 'axes.axisbelow'
> 
> Notice that the matplotlib module which was previously imported got
> changed by the import of the toolkit which declared itself a namespace
> package. Now this may be the result of mpl not using namespace
> packages correctly (eg matplotlib/__init__.py should be empty save for
> the namespace package or something like that)
Probably. In setuptools 0.7, they can have stuff in them, but all of them must
be identical. If you are using an unmodified matplotlib/__init__.py in the main
matplotlib package, then the "if 0:" is preventing the declaration of the
namespace package, and that may be contributing.
Also, neither matplotlib nor matplotlib.toolkits is named as a namespace_package
in matplotlib's setup.py, and both have to be. Similarly, basemap (for example)
only lists matplotlib.toolkits but not matplotlib.
> but I gotta tell ya,
> this looks just plain wrong. Had I not known that namespace packages
> were funky like this, it could have taken me a long time to trace this
> bug.
Well, when you do exactly what you were told not to do, this is what happens.
Don't make me break out the "Doctor, it hurts when I do this!" bromide. If you
don't want to bother to learn to use namespace packages correctly, that's
perfectly fine; just don't use them. But certainly don't blame the tools for
your mistake.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Dec 13, 2007 11:47 AM, Eric Firing <ef...@ha...> wrote:
>
> Fernando Perez wrote:
> > On Dec 13, 2007 11:18 AM, John Hunter <jd...@gm...> wrote:
> >> Do we need namespace packages in toolkits? I recently added gtktools
> >> and exceltools to toolkits, and got a very hard to debug error:
> >
> > Welcome to the wonderful world of setuptools' under-the-covers magic :)
>
> Fernando,
>
> Was this also the culprit that you and someone from enthought identified
> as causing the slow startup when using traits? This was a while back
> when I was complaining about a big startup time increase with Darren's
> traits-enabled configuration scheme.
Kind of, in a general sense. As best as we understood it from simple
profiling runs, the issue was that when NS packages are enabled, the
number of filesystem calls made in path searches explodes. That's
obviously always going to be a problem, but it's particularly
concerning for those of us (like John and myself) who live in
environments where most things are network-mounted disks (NFS,
typically). Tens of thousands of path searches over the network can
really cause a hit.
But setuptools is complex enough that I don't want to badmouth it
without a very precise analysis of the real root causes of the
problems, which I don't have time for right now. I just know that
using it well will require some understanding of its behavior, which
is a bit 'magic' at times.
Cheers,
f

Fernando Perez wrote:
> On Dec 13, 2007 11:18 AM, John Hunter <jd...@gm...> wrote:
>> Do we need namespace packages in toolkits? I recently added gtktools
>> and exceltools to toolkits, and got a very hard to debug error:
> 
> Welcome to the wonderful world of setuptools' under-the-covers magic :)
Fernando,
Was this also the culprit that you and someone from enthought identified 
as causing the slow startup when using traits? This was a while back 
when I was complaining about a big startup time increase with Darren's 
traits-enabled configuration scheme.
Eric

On Dec 13, 2007 11:18 AM, John Hunter <jd...@gm...> wrote:
> Do we need namespace packages in toolkits? I recently added gtktools
> and exceltools to toolkits, and got a very hard to debug error:
Welcome to the wonderful world of setuptools' under-the-covers magic :)
Cheers,
f

Do we need namespace packages in toolkits? I recently added gtktools
and exceltools to toolkits, and got a very hard to debug error:
In [1]: import matplotlib
In [2]: matplotlib.__file__
Out[2]: '/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.pyc'
In [3]: matplotlib.rcParams['axes.axisbelow']
Out[3]: False
In [4]: import matplotlib.toolkits.gtktools
In [5]: matplotlib.__file__
Out[5]: '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/matplotlib/__init__.pyc'
In [6]: matplotlib.rcParams['axes.axisbelow']
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
KeyError: 'axes.axisbelow'
Notice that the matplotlib module which was previously imported got
changed by the import of the toolkit which declared itself a namespace
package. Now this may be the result of mpl not using namespace
packages correctly (eg matplotlib/__init__.py should be empty save for
the namespace package or something like that) but I gotta tell ya,
this looks just plain wrong. Had I not known that namespace packages
were funky like this, it could have taken me a long time to trace this
bug.
I am going to comment out the toolkits namespace package code until I
hear persuasive arguments to the contrary, and until we fix the rest
of mpl to work properly with them.
JDH

I moved the tools in mlab that did optional imports (the rec2gtk and
rec2excel functions and their dependencies) out of mlab into
toolkits.gtktools and toolkits.exceltools. As Michael noted, these
imports can be expensive for users with gtk on their system and do not
belong in mlab. In some cases, eg logged in over a dumb terminal with
no x11 but where gtk is present, they also trigger text warnings or
errors from gtk, so are a nuisance. I thought it was worth cleaning
this up for the bugfix release.
If you get a minute to test before the release, that would help -- the
excel part requires pyExcelerator, which is pure python
http://sourceforge.net/projects/pyexcelerator
import gtk
import matplotlib.mlab as mlab
import matplotlib.toolkits.gtktools as gtktools
import matplotlib.toolkits.exceltools as exceltools
r = mlab.csv2rec('test.csv', checkrows=0)
formatd = dict(
 weight = mlab.FormatFloat(2),
 change = mlab.FormatPercent(2),
 cost = mlab.FormatThousands(2),
 )
exceltools.rec2excel(r, 'test.xls', formatd=formatd)
mlab.rec2csv(r, 'test.csv', formatd=formatd)
scroll = gtktools.rec2gtk(r, formatd=formatd, autowin=False)
win = gtk.Window()
win.set_size_request(600,800)
win.add(scroll)
win.show_all()
gtk.main()

On Thursday 13 December 2007 10:05:22 am Gael Varoquaux wrote:
> On Thu, Dec 13, 2007 at 09:31:03AM -0500, Darren Dale wrote:
> > It is possible to save the current settings to a file, so only those that
> > deviate from the default are written to the file. By putting the comments
> > on the same line as the data, you encourage users to comment their config
> > files accordingly, but comments appearing on the same line as the data
> > will be deleted if the current settings are saved. Also, what happens
> > when the comment is many lines long, like the comment for matplotlib's
> > timezone setting? I have a feeling there are formatting issues with this
> > scheme.
> >
> > I think I prefer the existing behavior, where the comment appears on a
> > seperate line just before the data. Maybe I don't understand the point of
> > your modifications.
>
> If I type "options <Rtn>", I don't understand what kind of object I have.
> It looks like a string to me, and it is not obvious that it actually is
> an object that I can modify by accessing its attributes. Currently if I
> don't know what the object is, it is not obvious what to do with it.
>
> I don't like the current way it is print (in the repository), because it
> is too long, and looks too much like a string. I am not sure my option is
> great because of your remark, and because it still looks a lot like a
> string.
>
> Second try, how to you like this:
>
> In [1]: import simpleconf
>
> In [2]: simpleconf.SimpleConfig()
> Out[2]:
> <SimpleConfig configuration object at 138452492>
>
> |-> datafile: 'data.txt' (a value of type 'str' or a value of type
> | 'unicode') -> solver: 'Direct' ('Direct' or 'Iterative')
> |-> Protocol.max_users: 1 (a value of type 'int')
> |-> Protocol.ptype: 'http' ('http' or 'ftp' or 'ssh')
>
> This feels a bit more like a Python object. I am still not terribly happy
> with the way the options are presented. It is not obvious they are simply
> attributes.
That feels more like a C++ object to me. Plus, you have a formatting issue due 
to a long comment. The solver setting is easily overlooked. This example 
doesn't make the sections as clear as the current implementation, where 
Protocol would be unindented, and all of the protocol settings would be 
indented.
Darren

On Thu, Dec 13, 2007 at 09:31:03AM -0500, Darren Dale wrote:
> It is possible to save the current settings to a file, so only those that 
> deviate from the default are written to the file. By putting the comments on 
> the same line as the data, you encourage users to comment their config files 
> accordingly, but comments appearing on the same line as the data will be 
> deleted if the current settings are saved. Also, what happens when the 
> comment is many lines long, like the comment for matplotlib's timezone 
> setting? I have a feeling there are formatting issues with this scheme.
> I think I prefer the existing behavior, where the comment appears on a 
> seperate line just before the data. Maybe I don't understand the point of 
> your modifications.
If I type "options <Rtn>", I don't understand what kind of object I have.
It looks like a string to me, and it is not obvious that it actually is
an object that I can modify by accessing its attributes. Currently if I
don't know what the object is, it is not obvious what to do with it.
I don't like the current way it is print (in the repository), because it
is too long, and looks too much like a string. I am not sure my option is
great because of your remark, and because it still looks a lot like a
string.
Second try, how to you like this:
In [1]: import simpleconf
In [2]: simpleconf.SimpleConfig()
Out[2]: 
<SimpleConfig configuration object at 138452492>
|-> datafile: 'data.txt' (a value of type 'str' or a value of type 'unicode')
|-> solver: 'Direct' ('Direct' or 'Iterative')
|-> Protocol.max_users: 1 (a value of type 'int')
|-> Protocol.ptype: 'http' ('http' or 'ftp' or 'ssh')
This feels a bit more like a Python object. I am still not terribly happy
with the way the options are presented. It is not obvious they are simply
attributes.
Gaël

On Thursday 13 December 2007 04:24:21 am Gael Varoquaux wrote:
> On Thu, Dec 13, 2007 at 09:30:44AM +0100, Gael Varoquaux wrote:
> > On Wed, Dec 12, 2007 at 06:39:02PM -0700, Fernando Perez wrote:
> > > On second thought though: __str__ is the one meant for 'human
> > > consumption', while __repr__ is deliberately meant to be much more
> > > machine-like. Basically the idea is that, whenever possible, one can
> > > do
> > >
> > > x == eval(repr(x))
> > >
> > > That is true for many of the builtin data types of the language.
> >
> > I totally agree. However if a user types:
> > pylab.rcParams
> > in IPython, or the Python interpreter, she gets the repr, AFAIK. I would
> > like this display to be readable.
>
> OK, this is what I currently have:
>
> """
> In [1]: import simpleconf
>
> In [2]: simpleconf.SimpleConfig()
> Out[2]:
> datafile = 'data.txt' # a value of type 'str' or a value of type
> 'unicode' solver = 'Direct' # 'Direct' or 'Iterative'
> Protocol.max_users = 1 # a value of type 'int'
> Protocol.ptype = 'http' # 'http' or 'ftp' or 'ssh'
> """
>
> I would like to make it as easy as possible for users to understand how
> to modify configuration options. Comments are welcomed.
It is possible to save the current settings to a file, so only those that 
deviate from the default are written to the file. By putting the comments on 
the same line as the data, you encourage users to comment their config files 
accordingly, but comments appearing on the same line as the data will be 
deleted if the current settings are saved. Also, what happens when the 
comment is many lines long, like the comment for matplotlib's timezone 
setting? I have a feeling there are formatting issues with this scheme.
I think I prefer the existing behavior, where the comment appears on a 
seperate line just before the data. Maybe I don't understand the point of 
your modifications.
Darren

Thanks for finding these. I suspect that is related to the migration 
from numarray to numpy.
I have fixed logo.py and mri_demo.py. I believe the rc_traits.py is 
correct (that "Float" is from traits, not numpy).
Cheers,
Mike
Nils Wagner wrote:
> On 2007年12月13日 09:07:42 +0100
> "Nils Wagner" <nw...@ia...> wrote:
>> Hi all,
>>
>> It should be float32 instead of Float32.
>>
>> python logo.py
>> Traceback (most recent call last):
>> File "logo.py", line 7, in ?
>> x = 1000*0.1*fromstring(
>> NameError: name 'Float32' is not defined
>>
>> Nils
>>
> 
> Actually there are some more NameErrors in the examples
> 
> grep -w 'Float*' *.py
> mri_demo.py:im = fromstring(file(dfile, 'rb').read(), 
> UInt16).astype(Float)
> rc_traits.py: linewidth = traits.Float(0.5)
> rc_traits.py: markeredgewidth = traits.Float(0.5)
> rc_traits.py: markersize = traits.Float(6)
> rc_traits.py: linewidth = traits.Float(1.0)
> rc_traits.py: linewidth = traits.Float(0.5)
> 
> python mri_demo.py
> Traceback (most recent call last):
> File "mri_demo.py", line 6, in ?
> im = fromstring(file(dfile, 'rb').read(), 
> UInt16).astype(Float)
> NameError: name 'UInt16' is not defined
> 
> 
> Nils
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA