[matplotlib-devel] Typo in logo.py
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in logo.py
On Thu, 13 Dec 2007 09:07:42 +0100 "Nils Wagner" <[EMAIL PROTECTED]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in logo.py
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 Thu, 13 Dec 2007 09:07:42 +0100 > "Nils Wagner" <[EMAIL PROTECTED]> 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 > [email protected] > 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 ", 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]:
>
>
> |-> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 ", 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]:
|-> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mlab reorganization
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()
Date,Open,High,Low,Close,Volume,Adj Close
2007-04-11,35.00,35.20,34.86,34.95,30476200,34.95
2007-04-10,34.80,34.99,34.75,34.88,29279000,34.88
2007-04-09,35.10,35.15,34.75,34.78,26455900,34.78
2007-04-05,35.13,35.19,34.94,35.02,26625300,35.02
2007-04-04,35.37,35.38,35.07,35.11,34697400,35.11
2007-04-03,35.43,35.60,35.17,35.32,30965900,35.32
2007-04-02,35.36,35.53,35.11,35.29,23496200,35.29
2007-03-30,35.56,35.58,35.00,35.36,34170100,35.36
2007-03-29,35.60,35.73,35.34,35.55,27471800,35.55
2007-03-28,35.70,35.73,35.30,35.55,41421500,35.55
2007-03-27,35.80,35.90,35.66,35.79,29677300,35.79
2007-03-26,35.85,36.00,35.44,36.00,29675300,36.00
2007-03-23,35.79,35.91,35.60,35.82,33463800,35.82
2007-03-22,35.44,35.84,35.40,35.81,33626200,35.81
2007-03-21,34.75,35.70,34.73,35.48,50433800,35.48
2007-03-20,34.63,34.85,34.50,34.77,28264400,34.77
2007-03-19,34.50,34.67,34.43,34.67,26529200,34.67
2007-03-16,34.60,34.84,34.25,34.36,44797300,34.36
2007-03-15,34.20,34.68,34.11,34.52,35824800,34.52
2007-03-14,34.09,34.40,33.90,34.31,40571200,34.31
2007-03-13,34.27,34.38,34.01,34.09,38898100,34.09
2007-03-12,34.28,34.63,34.01,34.44,30206600,34.44
2007-03-09,34.57,34.64,34.22,34.32,34229800,34.32
2007-03-08,34.60,34.64,34.35,34.45,29124500,34.45
2007-03-07,34.74,34.75,34.32,34.33,38987200,34.33
2007-03-06,34.73,34.84,34.52,34.72,33997500,34.72
2007-03-05,34.74,34.97,34.52,34.55,32849400,34.55
2007-03-02,34.93,35.15,34.70,34.87,45176900,34.87
2007-03-01,34.61,35.22,34.32,35.00,51383500,35.00
2007-02-28,34.80,35.08,34.65,34.91,50719300,34.91
2007-02-27,35.30,35.69,34.50,34.66,62678500,34.66
2007-02-26,35.26,35.38,35.15,35.34,28910600,35.34
2007-02-23,35.33,35.35,35.09,35.10,38152200,35.10
2007-02-22,35.82,35.88,35.31,35.40,37663800,35.40
2007-02-21,35.99,36.10,35.82,35.91,34670300,35.63
2007-02-20,35.86,36.13,35.75,36.11,23545600,35.83
2007-02-16,36.07,36.10,35.87,35.87,31049400,35.59
2007-02-15,36.36,36.47,36.06,36.14,28618800,35.86
2007-02-14,35.93,36.50,35.79,36.47,31908100,36.19
2007-02-13,35.64,35.90,35.64,35.77,22963000,35.49
2007-02-12,35.55,35.88,35.55,35.64,19010300,35.36
2007-02-09,35.71,35.84,35.48,35.53,29808800,35.25
2007-02-08,36.06,36.06,35.60,35.74,33678200,35.46
2007-02-07,36.32,36.35,36.06,36.10,21371700,35.82
2007-02-06,36.40,36.44,36.23,36.31,2273,36.03
2007-02-05,36.27,36.48,36.20,36.37,26202100,36.09
2007-02-02,36.26,36.40,36.12,36.27,25107200,35.99
2007-02-01,36.18,36.24,35.76,36.23,37868900,35.95
2007-01-31,36.00,36.22,35.83,36.05,36164300,35.77
2007-01-30,36.20,36.34,35.76,36.03,43142100,35.75
2007-01-29,36.07,36.35,36.03,36.19,24947500,35.91
2007-01-26,36.45,36.55,36.01,36.07,25923800,35.79
2007-01-25,36.65,36.70,36.26,36.34,25830200,36.06
2007-01-24,36.70,36.75,36.52,36.64,21458500,36.35
2007-01-23,36.68,36.74,36.38,36.55,35136000,36.27
2007-01-22,37.13,37.33,36.59,36.75,41384700,36.46
2007-01-19,37.15,37.50,36.85,36.95,62906000,36.66
2007-01-18,38.01,38.17,37.26,38.00,41619200,37.70
2007-01-17,38.18,38.28,37.85,37.98,30462800,37.68
2007-01-16,38.00,38.25,37.93,38.11,31118200,37.81
2007-01-12,37.84,38.00,37.67,37.89,25944000,37.59
2007-01-11,37.50,37.96,37.42,37.92,30831700,37.62
2007-01-10,37.38,37.61,37.34,37.56,23996600,37.27
2007-01-09,37.78,37.99,37.36,37.55,24597400,37.26
2007-01-08,37.45,37.67,37.25,37.55,23713700,37.26
2007-01-05,37.57,37.76,37.31,37.56,27027200,37.27
2007-01-04,37.97,38.00,37.45,37.75,31288800,37.46
2007-01-03,37.41,38.15,37.38,37.97,43222800,37.67
2006-12-29,37.48,37.52,37.16,37.21,25271100,36.92
2006-12-28,37.76,37.76,37.45,37.48,16862500,37.19
2006-12-27,37.79,38.03,37.57,37.79,16016200,37.50
2006-12-26,37.60,37.74,37.43,37.71,11997100,37.42
2006-12-22,37.89,37.90,37.51,37.57,15578900,37.28
2006-12-21,38.05,38.06,37.63,37.77,24847000,37.48
20
[matplotlib-devel] namespace packages in toolkits?
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 "", 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] namespace packages in toolkits?
On Dec 13, 2007 11:18 AM, John Hunter <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] namespace packages in toolkits?
Fernando Perez wrote: > On Dec 13, 2007 11:18 AM, John Hunter <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] namespace packages in toolkits?
On Dec 13, 2007 11:47 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > > Fernando Perez wrote: > > On Dec 13, 2007 11:18 AM, John Hunter <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] namespace packages in toolkits?
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 "", 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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.10002 >>> b 0.10001 >>> 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 [EMAIL PROTECTED] - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
On Dec 13, 2007 4:14 PM, Christopher Barker <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] modifying TConfig
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
