matplotlib-devel Mailing List for matplotlib (Page 13)

On Monday 16 July 2007 01:25:18 pm Eric Firing wrote:
> Michael Droettboom wrote:
> > Darren Dale wrote:
> >> If not, should we use
> >> u'\xd7' or '=C3=97' in the actual sources (the latter requiring the fi=
le's
> >> encoding to be declared at the beginning of the file, like: # -*-
> >> coding: utf-8 -*-)?
> >
> > In an ideal world, I would prefer the latter, but we would want to
> > verify that all the matplotlib developers are using an editor that
> > respects those tags, or we could run into surprises if the files are
> > accidentally re-encoded.
> >
> > Cheers,
> > Mike
>
> I use a good old-fashioned editor called zed, written by an Italian
> named Sandro Serrafini who seems to have left no trace for several
> years. I have modified it slightly, and I do minimal maintenance to
> keep it compiling with new OS releases. Yes, I am familiar with emacs
> and vi and nano and gedit and jed; I periodically survey the field of
> editors. And yes, emacs will brew your morning coffee, but no, it won't
> behave in the sane ways that I like an editor to behave.
>
> So the suggestion to start using unicode in source code is a nightmare
> for me. Ascii is good: simple, universal, easy to work with, easy to
> understand. One byte, one character. Unambiguous.=20
What about rendering unicode, but keeping the mpl sources ascii only?
> Undoubtedly unicode=20
> makes sense for the world in the long run, but for me it is an
> unadulterated pain.
In that case, I imagine you are not eagerly anticipating the arrival of Py3=
K.

On 7/16/07, Eric Firing <ef...@ha...> wrote:
> I use a good old-fashioned editor called zed, written by an Italian
> named Sandro Serrafini who seems to have left no trace for several
> years. I have modified it slightly, and I do minimal maintenance to
> keep it compiling with new OS releases. Yes, I am familiar with emacs
> and vi and nano and gedit and jed; I periodically survey the field of
> editors. And yes, emacs will brew your morning coffee, but no, it won't
> behave in the sane ways that I like an editor to behave.
>
> So the suggestion to start using unicode in source code is a nightmare
> for me. Ascii is good: simple, universal, easy to work with, easy to
> understand. One byte, one character. Unambiguous. Undoubtedly unicode
> makes sense for the world in the long run, but for me it is an
> unadulterated pain.
I am a huge emacs user, am am familiar with coffee.el though have
never used it, but I think putting unicode into the src is a bad idea.
 Wouldn't this cause potential problems for people working over dumb
terminals?
JDH

Michael Droettboom wrote:
> Darren Dale wrote:
>> If not, should we use 
>> u'\xd7' or ×ばつ' in the actual sources (the latter requiring the file's 
>> encoding to be declared at the beginning of the file, like: # -*- coding: 
>> utf-8 -*-)?
> In an ideal world, I would prefer the latter, but we would want to 
> verify that all the matplotlib developers are using an editor that 
> respects those tags, or we could run into surprises if the files are 
> accidentally re-encoded.
> 
> Cheers,
> Mike
I use a good old-fashioned editor called zed, written by an Italian 
named Sandro Serrafini who seems to have left no trace for several 
years. I have modified it slightly, and I do minimal maintenance to 
keep it compiling with new OS releases. Yes, I am familiar with emacs 
and vi and nano and gedit and jed; I periodically survey the field of 
editors. And yes, emacs will brew your morning coffee, but no, it won't 
behave in the sane ways that I like an editor to behave.
So the suggestion to start using unicode in source code is a nightmare 
for me. Ascii is good: simple, universal, easy to work with, easy to 
understand. One byte, one character. Unambiguous. Undoubtedly unicode 
makes sense for the world in the long run, but for me it is an 
unadulterated pain.
Eric

Darren Dale wrote:
> If not, should we use 
> u'\xd7' or ×ばつ' in the actual sources (the latter requiring the file's 
> encoding to be declared at the beginning of the file, like: # -*- coding: 
> utf-8 -*-)?
In an ideal world, I would prefer the latter, but we would want to 
verify that all the matplotlib developers are using an editor that 
respects those tags, or we could run into surprises if the files are 
accidentally re-encoded.
Cheers,
Mike

I am cleaning up some of the code in ticker.ScalarFormatter, specifically s=
ome=20
of the text formatting for dealing with scientific notation.=20
We provide an option to format labels in sci. notation without using mathte=
xt=20
or usetex, in which case I would like to use the unicode multiplication sig=
n,=20
=C3=97 instead of x. Is there any reason not to do so? If not, should we us=
e=20
u'\xd7' or '=C3=97' in the actual sources (the latter requiring the file's=
=20
encoding to be declared at the beginning of the file, like: # -*- coding:=20
utf-8 -*-)? If we can use unicode, it might be nice to use real minus signs=
=20
as well, =E2=88=92123 rather than -123.
Darren

On 7/15/07, Paul Kienzle <pki...@ni...> wrote:
> Hi,
>
> I don't see an obvious way to remove a line from an axes object.
>
> Shall I add remove_child(h) which searches through all the lists
> of containers and removes the one that I don't want?
That's one way to do it, but you might consider something along the
lines -- every time someone adds an Artist anywhere in the figure,
they add an entry into a Figure remove dictionary that maps the artist
to a function to remove it
class Figure:
 def register_remove(self, artist, func):
 'register a function to remove an artist'
 self.removemap[artist] = func
 self.lastArtist = artist # this can be used to handle Gael's request
 def remove_artist(self, artist):
 'remove the artist'
 func = self.removemap.get(artist, None)
 if func is None: return
 func() # poof, it's gone
 del self.removemap(artist)
 def remove_last(self):
 'remove the most recently registered artist'
 self.remove_artist(self.lastArtist)
 self.lastArtist = None
class Axes:
 def add_line(self, line):
 self.figure.register_remove(line, lambda x: self.lines.remove(line))
 self.lines.append(line)
Then the user won't need to know whether the artist is stored by the
Axes, Axis, XTick, etc... This is likely more efficient and easier to
implement than recursively searching....
Users can then:
line, = ax.plot(something)
fig.remove_artist(line)
or
ax.fill(something)
fig.remove_last()
and a pylab interface will be trival
def remove_last():
 gcf().remove_last()
JDH

As a stopgap measure until someone with more knowledge of these changes 
replies, the following worked for me. In setup.py, uncomment the old 
distutils import, and comment the new setuptools import:
#from distutils.core import Extension, setup
from setuptools import setup
to
from distutils.core import Extension, setup
#from setuptools import setup
Obviously not the "real" fix, but I was able to install and use pylab.
Cheers,
Mike
Darren Dale wrote:
> This morning I am having trouble installing from the svn repository. My home 
> machine does not have setuptools installed, and the standard python setup.py 
> install fails because it wants to import setuptools.
>
> If I install setuptools, I am able to install, but not run pylab:
>
> In [1]: from pylab import *
> ---------------------------------------------------------------------------
> <type 'exceptions.Exception'> Traceback (most recent call last)
>
> /home/darren/<ipython console> in <module>()
>
> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py 
> in <module>()
> ----> 1 from matplotlib.pylab import *
> 2 import matplotlib.pylab
> 3 __doc__ = matplotlib.pylab.__doc__
>
> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/pylab.py 
> in <module>()
> 198 """
> 199 import sys, warnings
> --> 200 import cm
> 201 import _pylab_helpers
> 202 import mlab #so I can override hist, psd, etc...
>
> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/cm.py 
> in <module>()
> 4
> 5 import matplotlib as mpl
> ----> 6 import matplotlib.colors as colors
> 7 import matplotlib.numerix.npyma as ma
> 8 import matplotlib.cbook as cbook
>
> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/colors.py 
> in <module>()
> 36 import re
> 37 import warnings
> ---> 38 import numpy as npy
> 39 import matplotlib.numerix.npyma as ma
> 40 import matplotlib.cbook as cbook
>
> /usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/__init__.py 
> in <module>()
> 44 import fft
> 45 import random
> ---> 46 import ctypeslib
> 47
> 48 # Make these accessible from numpy name-space
>
> /usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/ctypeslib.py 
> in <module>()
> 7
> 8 try:
> ----> 9 import ctypes
> 10 except ImportError:
> 11 ctypes = None
>
> /usr/lib/python2.5/site-packages/ctypes/__init__.py in <module>()
> 26
> 27 if __version__ != _ctypes_version:
> ---> 28 raise Exception, ("Version number mismatch", __version__, 
> _ctypes_version)
> 29
> 30 if _os.name in ("nt", "ce"):
>
> <type 'exceptions.Exception'>: ('Version number mismatch', '1.0.0', '1.0.2')
>
> Darren
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

This morning I am having trouble installing from the svn repository. My home 
machine does not have setuptools installed, and the standard python setup.py 
install fails because it wants to import setuptools.
If I install setuptools, I am able to install, but not run pylab:
In [1]: from pylab import *
---------------------------------------------------------------------------
<type 'exceptions.Exception'> Traceback (most recent call last)
/home/darren/<ipython console> in <module>()
/usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py 
in <module>()
----> 1 from matplotlib.pylab import *
 2 import matplotlib.pylab
 3 __doc__ = matplotlib.pylab.__doc__
/usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/pylab.py 
in <module>()
 198 """
 199 import sys, warnings
--> 200 import cm
 201 import _pylab_helpers
 202 import mlab #so I can override hist, psd, etc...
/usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/cm.py 
in <module>()
 4
 5 import matplotlib as mpl
----> 6 import matplotlib.colors as colors
 7 import matplotlib.numerix.npyma as ma
 8 import matplotlib.cbook as cbook
/usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/colors.py 
in <module>()
 36 import re
 37 import warnings
---> 38 import numpy as npy
 39 import matplotlib.numerix.npyma as ma
 40 import matplotlib.cbook as cbook
/usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/__init__.py 
in <module>()
 44 import fft
 45 import random
---> 46 import ctypeslib
 47
 48 # Make these accessible from numpy name-space
/usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/ctypeslib.py 
in <module>()
 7
 8 try:
----> 9 import ctypes
 10 except ImportError:
 11 ctypes = None
/usr/lib/python2.5/site-packages/ctypes/__init__.py in <module>()
 26
 27 if __version__ != _ctypes_version:
---> 28 raise Exception, ("Version number mismatch", __version__, 
_ctypes_version)
 29
 30 if _os.name in ("nt", "ce"):
<type 'exceptions.Exception'>: ('Version number mismatch', '1.0.0', '1.0.2')
Darren

On Sun, Jul 15, 2007 at 10:49:13PM -0400, Paul Kienzle wrote:
> I don't see an obvious way to remove a line from an axes object.
> Shall I add remove_child(h) which searches through all the lists
> of containers and removes the one that I don't want?
I think that would be very useful. TVTK has something similar, and I use
it often. Something to remove the last object added we be great too (I
don't know where the reference to the last object added should be stored,
but there are many places, and perhaps maybe simply as an attribute of
the "remove_last" function. And I suggest that this should not be a
method of axes or a figure, but a pylab function.
Cheers,
Gaël

Hi,
I've made some progress on an MPL canvas infrastructure built on top of the
contains() methods patch I submitted earlier (and now in svn).
I would like to post it to svn so that interested parties can play with it
and contribute to the development, but it is not yet ready to be put in the
trunk. I was browsing the svn tree looking for a sandbox to put it in, but
the closest I found is /matplotlib/branches. Any objections to me putting 
it into /matplotlib/branches/canvas?
Thanks in advance,
	- Paul

Hi all,
A new matplotlib-checkins mailing list has been created for SVN commit
notification.
You can subscribe to it by visiting:
https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins
Cheers,
Edin

Hi,
I don't see an obvious way to remove a line from an axes object.
Shall I add remove_child(h) which searches through all the lists
of containers and removes the one that I don't want?
For now I will rerender the graph without the missing child.
	- Paul

John Hunter wrote:
> On 7/15/07, Eric Firing <ef...@ha...> wrote:
> \> docstring still blathers on about pylab functions, however; I suspect we
>> should change this to something more unique and helpful, such as a
>> directory of matplotlib submodules and/or an intro to the useful things
>> in matplotlib.__init__.py like rcParams.
> 
> Verg good idea -- are you volunteering? :-)
OK.
Eric

On 7/15/07, Eric Firing <ef...@ha...> wrote:
\> docstring still blathers on about pylab functions, however; I suspect we
> should change this to something more unique and helpful, such as a
> directory of matplotlib submodules and/or an intro to the useful things
> in matplotlib.__init__.py like rcParams.
Verg good idea -- are you volunteering? :-)
JDH
PS: in other news, I find it ironic that the gmail spell checker,
which underlines words it doesn't recognize with a red line (eg
rcParams), doesn't recognize the word "gmail"

Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
> If I say
> 
>>>> import matplotlib
>>>> help(matplotlib)
> 
> (This is with 0.90.0 by the way)
> 
> It basically gives me the help I'd expect for pylab. Oh, and it says 
> "the" instead of "to". It's a little weird thinking of a library as the 
> top level with the main interface as a module. I guess the interface is 
> just another component of the library. Though when I
> 
>>>> import pylab
>>>> help(pylab)
> 
> I get what looks like help for numpy. Perhaps my installation is strange?
> 
I have fixed this. The problem was that when you import pylab, it 
imports a stub "pylab.py" from site-packages, which in turn imports 
everything from matplotlib/pylab.py. The matplotlib.pylab docstring 
does not get transferred to the newly loaded pylab module, however. The 
solution was to do that transfer explicitly in the pylab.py stub. I 
also made slight tweaks to the pylab.py and matplotlib.py docstrings to 
try to clarify the pylab-matplotlib relationship. The matplotlib 
docstring still blathers on about pylab functions, however; I suspect we 
should change this to something more unique and helpful, such as a 
directory of matplotlib submodules and/or an intro to the useful things 
in matplotlib.__init__.py like rcParams.
Eric

John Hunter wrote:
> On 7/13/07, Eric Firing <ef...@ha...> wrote:
> 
>> No, it is not your installation. You have identified an area that needs
>> work, after we settle on a possibly new import and namespace strategy.
> 
> This is definitely something new -- help(pylab) used to display the
> rather extensive pylab doc string, which starts with in pylab.py:
> 
> ""
> This is a matlab(TM) style interface to matplotlib.
> 
> The following plotting commands are provided; some of these do not
> exist in matlab(TM) but have proven themselves to be useful
> nonetheless.
> The majority of them, however, have matlab analogs
> ...snip
> """
> 
> Are eggs doing something fishy here? This is a weird one.
> JDH
But it does it on linux, not using eggs. I couldn't figure it out--just 
 assumed it had always done that, and I had never noticed.
Still, the matplotlib/__init__.py docstring could be changed to make 
clear the distinction between mpl and the pylab interface. Instead, it 
talks only about the latter:
efiring@manini:~/programs/py/mpl/matplotlib_units/lib/matplotlib$ head 
__init__.py
"""
This is a matlab(TM) style functional interface the matplotlib.
The following matlab(TM) compatible commands are provided by
 >>> from pylab import *
Plotting commands
 axes - Create a new axes
Eric

On 7/13/07, Eric Firing <ef...@ha...> wrote:
> No, it is not your installation. You have identified an area that needs
> work, after we settle on a possibly new import and namespace strategy.
This is definitely something new -- help(pylab) used to display the
rather extensive pylab doc string, which starts with in pylab.py:
""
This is a matlab(TM) style interface to matplotlib.
The following plotting commands are provided; some of these do not
exist in matlab(TM) but have proven themselves to be useful
nonetheless.
The majority of them, however, have matlab analogs
...snip
"""
Are eggs doing something fishy here? This is a weird one.
JDH

OK, I reverted back to the tried and true MPL way... It hasn't been 
completely unproductive, however: I added tests for infinity (either 
sign) and finite-ness to MPL_isnan.h. (On top of which I now understand 
the IEEE 754 representations far better than I care to.)
Now, this should work just like it did in the good old days... I mean it 
this time. :)
John, commence using your infinity-finding powers!
-Andrew

Can you stick this in the top of src/_transforms.cpp and see if you
still get the problem?
#define _GLIBCPP_USE_C99
-Andrew
John Hunter wrote:
> On 7/13/07, Andrew Straw <str...@as...> wrote:
>> I think I figured out and fixed the situation with isnan.
>>
>> >From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
>>
>>> Basically the story is this:
>>> isnan() is a C99 extension to standard C.
>>> Standard C++ is based on an older standard of C.
>>> Hence isnan() is not part of standard C++ and may or may not work.
>> But std::isnan() is part of standard C++ defined in <cmath>.
>>
>> Since we use C++ (which numpy doesn't) we can drop our own isnan support
>> and use std::isnan(). Which I just did.
> 
> We're not out of the woods yet. On my OS X 10.3 powerbook
> 
> src/transforms.cpp: In member function `Py::Object Bbox::update(const
> Py::Tuple&)':
> src/transforms.cpp:476: error: `isnan' undeclared in namespace `std'
> src/transforms.cpp:476: error: `isnan' undeclared in namespace `std'
> 
> John-Hunters-Computer:~/mpl> gcc --version
> gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 7/13/07, Andrew Straw <str...@as...> wrote:
> I think I figured out and fixed the situation with isnan.
>
> >From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
>
> >
> > Basically the story is this:
> > isnan() is a C99 extension to standard C.
> > Standard C++ is based on an older standard of C.
> > Hence isnan() is not part of standard C++ and may or may not work.
>
> But std::isnan() is part of standard C++ defined in <cmath>.
>
> Since we use C++ (which numpy doesn't) we can drop our own isnan support
> and use std::isnan(). Which I just did.
We're not out of the woods yet. On my OS X 10.3 powerbook
src/transforms.cpp: In member function `Py::Object Bbox::update(const
 Py::Tuple&)':
src/transforms.cpp:476: error: `isnan' undeclared in namespace `std'
src/transforms.cpp:476: error: `isnan' undeclared in namespace `std'
John-Hunters-Computer:~/mpl> gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)
JDH

It seems to be working now. Thanks!
This is a perfect example of quick response. I keep telling people 
that, sure, the scientific python suite has occasional bugs, but the 
community is *very* responsive. This is a perfect example. Thanks 
to everybody that helped,
-Rob
> Rob, you should be able to compile now as of r3515.
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
> If I say
> 
>>>> import matplotlib
>>>> help(matplotlib)
> 
> (This is with 0.90.0 by the way)
> 
> It basically gives me the help I'd expect for pylab. Oh, and it says 
> "the" instead of "to". It's a little weird thinking of a library as the 
> top level with the main interface as a module. I guess the interface is 
> just another component of the library. Though when I
> 
>>>> import pylab
>>>> help(pylab)
> 
> I get what looks like help for numpy. Perhaps my installation is strange?
> 
No, it is not your installation. You have identified an area that needs 
work, after we settle on a possibly new import and namespace strategy.
Eric

Christopher Barker wrote:
> John Hunter wrote:
[...]
> I do wish that:
> 
>>>> import matplotlib as mpl
>>>> import mpl.artist
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ImportError: No module named mpl.artist
> 
> worked.
The way I have it working now (on my machine, not in svn), when you
import matplotlib as mpl
You don't need to then import mpl.artist; it is already imported, ready 
for use.
Eric
> 
> -Chris
> 
> 
> 

John Hunter wrote:
> I don't think this will work in this form. artist is a module, and it
> is not imported simply by importing matplotlib
> 
> In [1]: import matplotlib as mpl
> 
> In [2]: mpl.artist
however, this seems to work (though it looks perhaps a bit odd)
>>> import matplotlib as mpl
>>> import matplotlib.artist
>>> mpl.artist
<module 'matplotlib.artist' from
'/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/artist.pyc'>
I do like this better -- names like mpl_*** rub me the wrong way. it
looks like you really want a namespace -- and indeed you do!
maybe the real solution is to have the matplotlib called "mpl" from the
get go, like wxPython does:
import wx
wx.Whatever...
I do wish that:
>>> import matplotlib as mpl
>>> import mpl.artist
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: No module named mpl.artist
worked.
-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...

I think I figured out and fixed the situation with isnan.
>From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
> 
> Basically the story is this:
> isnan() is a C99 extension to standard C.
> Standard C++ is based on an older standard of C.
> Hence isnan() is not part of standard C++ and may or may not work.
But std::isnan() is part of standard C++ defined in <cmath>.
Since we use C++ (which numpy doesn't) we can drop our own isnan support
and use std::isnan(). Which I just did.
The cmath header also defines isfinite and isinf. So, John, go at the
original change you wanted to make this morning, at least once the dust
settle and we're happy this will work on all target platforms (now
tested with gcc on Mac and Linux -- I'm afraid MSVC is beyond me right now).
-Andrew