matplotlib-devel Mailing List for matplotlib

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