matplotlib-devel Mailing List for matplotlib

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

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.
Gaël

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.
Gaël

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

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

On Dec 12, 2007 5:58 PM, Gael Varoquaux <gae...@no...> wrote:
> Hi,
>
> I definetely don't like the fact that .__repr__() and repr() are used all
> over TConfig for eg storing to file.
>
> First of all I would like to modify __repr__ for a TConfig class to give
> a more synthetic view.
>
> I propose to change the current ".__repr__()" method to ".tostring()" and
> to implement a more readable ".__repr__()".
>
> Are the different people interested in these issues OK with that? If yes,
I'm OK with it.
> where is the authoritative repo for TConfig? Which SVN should I start
> hacking?
It's probably easier for now to use ipython, since both you and Darren
both have SVN write access to it. Unless Darren has a different
opinion...
Cheers,
f

On Dec 12, 2007 7:16 AM, Paul Kienzle <pki...@ni...> wrote:
> I'm curious about the term 'threading backend'.
>
> Recently I posted a question about how to handle slow plots, suggesting
> that the backend canvas have an isabort() method so that the renderer
> can stop what it is doing and post the current bitmap as it stands.
> This is to support interactive operations such as panning and resizing
> on large data collections.
>
> Do you mean something similar when you say 'threading backend', and is
> it already supported in IPython?
No, it just means that ipython can run in conjunction with the major
GUI toolkits in a non-blocking manner. In a plain python shell, if
you open a plot window (for any backend other than Tk), you can't go
back to the prompt and keep typing until you close the plot. IPython
allows that to happen, with Wx, GTK, Qt and Qt4.
Cheers,
f

On Dec 12, 2007 6:34 PM, Darren Dale <dar...@co...> wrote:
>
> On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote:
> > Hi,
> >
> > I definetely don't like the fact that .__repr__() and repr() are used all
> > over TConfig for eg storing to file.
> >
> > First of all I would like to modify __repr__ for a TConfig class to give
> > a more synthetic view.
> >
> > I propose to change the current ".__repr__()" method to ".tostring()" and
> > to implement a more readable ".__repr__()".
> >
> > Are the different people interested in these issues OK with that? If yes,
> > where is the authoritative repo for TConfig? Which SVN should I start
> > hacking?
>
> I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it
> doesnt matter in practice because I keep the two in sync.
>
> I do want to be able to save the verbose information to a file, since we want
> to be able to generate a commented file that people can use to learn how to
> make modifications. If that doesnt change, I don't have an objection to
> making __repr__ terse.
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.
Quoting http://docs.python.org/ref/customization.html#l2h-179 :
__repr__( 	self)
 Called by the repr() built-in function and by string conversions
(reverse quotes) to compute the ``official'' string representation of
an object. If at all possible, this should look like a valid Python
expression that could be used to recreate an object with the same
value (given an appropriate environment). If this is not possible, a
string of the form "<...some useful description...>" should be
returned. The return value must be a string object. If a class defines
__repr__() but not __str__(), then __repr__() is also used when an
``informal'' string representation of instances of that class is
required.
 This is typically used for debugging, so it is important that the
representation is information-rich and unambiguous.
So Gael, would you be OK with a terser str() and leaving repr to honor
this python convention?
Cheers,
f

On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote:
> Hi,
>
> I definetely don't like the fact that .__repr__() and repr() are used all
> over TConfig for eg storing to file.
>
> First of all I would like to modify __repr__ for a TConfig class to give
> a more synthetic view.
>
> I propose to change the current ".__repr__()" method to ".tostring()" and
> to implement a more readable ".__repr__()".
>
> Are the different people interested in these issues OK with that? If yes,
> where is the authoritative repo for TConfig? Which SVN should I start
> hacking?
I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it 
doesnt matter in practice because I keep the two in sync. 
I do want to be able to save the verbose information to a file, since we want 
to be able to generate a commented file that people can use to learn how to 
make modifications. If that doesnt change, I don't have an objection to 
making __repr__ terse.
Darren

Hi,
I definetely don't like the fact that .__repr__() and repr() are used all
over TConfig for eg storing to file.
First of all I would like to modify __repr__ for a TConfig class to give
a more synthetic view.
I propose to change the current ".__repr__()" method to ".tostring()" and
to implement a more readable ".__repr__()".
Are the different people interested in these issues OK with that? If yes,
where is the authoritative repo for TConfig? Which SVN should I start
hacking?
Cheers,
Gaël