matplotlib-devel Mailing List for matplotlib

On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---------------------------------------------------------------------------
> exceptions.AttributeError Traceback (most recent
> call last)
>
> /home/darren/<ipython console>
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
> 54
> 55 # a hack to keep old versions of ipython working with mpl
> 56 if 'IPython.Shell' in sys.modules:
> ---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 58
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
> pylab_setup()
> 24 time.sleep(1)
> 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 26 globals(),locals(),[backend_name])
> 27
> 28 # Things we pull in from all backends
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
> 7 import cairo.gtk
> 8
> ----> 9 import matplotlib.backends.backend_cairo as be_cairo
> 10 from matplotlib.backends.backend_gtk import *
> 11
>
> AttributeError: 'module' object has no attribute 'backends'
I found a workaround, and committed it. I don't understand what the root of 
the problem was, probably because the AttributeError at the end of the 
Traceback is misleading. Changing this:
import matplotlib.backends.backend_cario as be_cairo
to this:
from matplotlib.backends import backend_cairo
and updating references to be_cairo was all that was needed. The fix is in svn 
2979.
Darren

On 2007年1月11日, Rich Shepard wrote:
> When I ran the script with -dWXAgg, it segfaulted.
 But, when I run with -dWX, it completes and displays the plot. Ergo,
there's something wrong with Agg here, I suppose.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On 2007年1月11日, Rich Shepard wrote:
 The last output files are attached.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On 2007年1月11日, Rich Shepard wrote:
On 2007年1月11日, John Hunter wrote:
> python simple_plot.py --verbose-debug -dAgg >& runagg.out
> python simple_plot.py --verbose-debug -dPS >& runps.out
> python simple_plot.py --verbose-debug -dGTK >& rungtk.out
 These three ran to completion. The last produced a window displaying the
 output.
 When I ran the script with -dWXAgg, it segfaulted.
 Two output files attached; original message bounced because the size was
too large.
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On Thursday 11 January 2007 02:01, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcair
> > >o.py", line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
>
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
>
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
I've been looking at this, but haven't made much progress. Try this with 
backend:gtkcairo in matplotlibrc:
$ python
>>> __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
<module 'matplotlib.backends.backend_ps' 
from '/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_ps.pyc'>
$ ipython
In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent 
call last)
/home/darren/<ipython console>
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
 54
 55 # a hack to keep old versions of ipython working with mpl
 56 if 'IPython.Shell' in sys.modules:
---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
 58
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in 
pylab_setup()
 24 time.sleep(1)
 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
---> 26 globals(),locals(),[backend_name])
 27
 28 # Things we pull in from all backends
/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
 7 import cairo.gtk
 8
----> 9 import matplotlib.backends.backend_cairo as be_cairo
 10 from matplotlib.backends.backend_gtk import *
 11
AttributeError: 'module' object has no attribute 'backends'
If you change backend:gtkagg in matplotlibrc, then ipython doesnt complain. 
Very strange.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> This is the official definition from the manual:
 Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
 Steve> alpha in the upper 8 bits, then red, then green, then
 Steve> blue. The 32-bit quantities are stored
 Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
 Steve> transparent red is 0x80800000, not 0x80ff0000.)
 Steve> What I think this means is: cairo ARGB32 is stored not as 4
 Steve> 8-bit quantities, but as one 32-bit int. On big-endian
 Steve> systems the byte order is ARGB, as you would expect, but on
 Steve> little-endian systems (like a PC) the byte order is BGRA.
 Steve> I imagine the reason is that its easier/faster to
 Steve> read/write one 32-bit int than it is to read/write four
 Steve> bytes.
OK, I see the source of my confusion. argb determines the order but
it doesn't determine whether the most significant bit is first or
last....
I added a method buffer_bgra32 to the image backend. I'm not sure
this is the right way to deal with the endianness bit it's easy and
will probably work. I'll leave it to you guys to fix the cairo
backend to selectively call the right method and test it across
platforms, or propose a better solution if you don't like this one...
JDH

On Thu, 2007年01月11日 at 08:50 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
> >> I only had a short time to work with backend_gtkcairo, but a
> >> couple of things caught my attention. mathtext support seemed
> >> to need some improvement, it looked like it was rendered as an
> >> image rather than as text. Also, imshow(rand(100,100)) looked
> >> very different with gtkcairo and gtkagg, (maybe because the
> >> rgba ordering is different in agg and cairo? I'm not sure this
> >> is even the case, I'm taking a stab in the dark.)
> 
> Steve> cairo mathtext uses a method copied from gdk/gtk and does
> Steve> render an image. It needs updating to render text.
> 
> Steve> imshow does look different on cairo and agg, and yes, It
> Steve> looks like an image format problem. cairo uses ARGB32 with
> Steve> pre-multiplied alpha, and the ARGB order depends on whether
> Steve> the machine is little- of big-endian.
> 
> I am confused by what you mean about the ARGB order depending on
> endianess. ARGB defines the order, and each color is one byte, so
> where is the ambiguity? Do you mean that depending on endianness,
> cairo will use other orderings than ARGB?
> 
> In _image.cpp we provide a few buffer methods for various pixel
> orderings, eg buffer_argb32. We may need to provide additional
> orderings for cairo, and call the right one depending on the platform.
This is the official definition from the manual:
CAIRO_FORMAT_ARGB32
each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then
red, then green, then blue. The 32-bit quantities are stored
native-endian. Pre-multiplied alpha is used. (That is, 50% transparent
red is 0x80800000, not 0x80ff0000.)
What I think this means is:
cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int.
On big-endian systems the byte order is ARGB, as you would expect, but
on little-endian systems (like a PC) the byte order is BGRA.
I imagine the reason is that its easier/faster to read/write one 32-bit
int than it is to read/write four bytes.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:
>> I have never run into a problem with relative imports, though I don't
>> object to removing them. Why are they bad style and what is the 
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two different modules in two different directories with the 
> same
> name and you import the wrong module by mistake.
Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:
 from .localpkg import Symbol1, Symbol2
 from . import localpkg
This disambiguates the "calendar.py" problem that you had (and that 
about 90% of python coders have had at least once in their lives). :)
-Peter

On Thursday 11 January 2007 09:42, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I had to alter the following lines from backend_gtkcairo,
> Darren> from
>
> Darren> import matplotlib.backends.backend_cairo as be_cairo from
> Darren> matplotlib.backends.backend_gtk import *
>
> Darren>
> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
>", Darren> line 11, in ? import matplotlib.backends.backend_cairo as
> Darren> be_cairo AttributeError: 'module' object has no attribute Darren>
> 'backends'
>
>
> My guess is that you were running your test code in which there was a
> "matplotlib" dir that was not *the* matplotlib install dir.
>
> Possible?
It wouldn't have been the first time I made that mistake, but that doesn't 
seem to be the problem.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
 >> I only had a short time to work with backend_gtkcairo, but a
 >> couple of things caught my attention. mathtext support seemed
 >> to need some improvement, it looked like it was rendered as an
 >> image rather than as text. Also, imshow(rand(100,100)) looked
 >> very different with gtkcairo and gtkagg, (maybe because the
 >> rgba ordering is different in agg and cairo? I'm not sure this
 >> is even the case, I'm taking a stab in the dark.)
 Steve> cairo mathtext uses a method copied from gdk/gtk and does
 Steve> render an image. It needs updating to render text.
 Steve> imshow does look different on cairo and agg, and yes, It
 Steve> looks like an image format problem. cairo uses ARGB32 with
 Steve> pre-multiplied alpha, and the ARGB order depends on whether
 Steve> the machine is little- of big-endian.
I am confused by what you mean about the ARGB order depending on
endianess. ARGB defines the order, and each color is one byte, so
where is the ambiguity? Do you mean that depending on endianness,
cairo will use other orderings than ARGB?
In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32. We may need to provide additional
orderings for cairo, and call the right one depending on the platform.
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I had to alter the following lines from backend_gtkcairo,
 Darren> from
 Darren> import matplotlib.backends.backend_cairo as be_cairo from
 Darren> matplotlib.backends.backend_gtk import *
 Darren> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
 Darren> line 11, in ? import matplotlib.backends.backend_cairo as
 Darren> be_cairo AttributeError: 'module' object has no attribute
 Darren> 'backends'
My guess is that you were running your test code in which there was a
"matplotlib" dir that was not *the* matplotlib install dir.
Possible?
JDH

On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote: 
> I only had a short time to work with backend_gtkcairo, but a couple of things 
> caught my attention. mathtext support seemed to need some improvement, it 
> looked like it was rendered as an image rather than as text. Also, 
> imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe 
> because the rgba ordering is different in agg and cairo? I'm not sure this is 
> even the case, I'm taking a stab in the dark.)
cairo mathtext uses a method copied from gdk/gtk and does render an
image. It needs updating to render text.
imshow does look different on cairo and agg, and yes, It looks like an
image format problem. cairo uses ARGB32 with pre-multiplied alpha, and
the ARGB order depends on whether the machine is little- of big-endian.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote:
> > I had to alter the following lines from backend_gtkcairo, from
> >
> > import matplotlib.backends.backend_cairo as be_cairo
> > from matplotlib.backends.backend_gtk import *
> >
> > to
> >
> > import backend_cairo as be_cairo
> > from backend_gtk import *
> >
> > in order to prevent the following traceback:
> >
> > Traceback (most recent call last):
> > File "/usr/bin/ipython", line 27, in ?
> > IPython.Shell.start().mainloop()
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > start
> > return shell(user_ns = user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > __init__
> > shell_class=MatplotlibMTShell)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > __init__
> > on_kill=[mainquit])
> > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > make_IPython
> > embedded=embedded,**kw)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > __init__
> > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > _matplotlib_config
> > from matplotlib import backends
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 55, in ?
> > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 23, in pylab_setup
> > globals(),locals(),[backend_name])
> >
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > line 11, in ?
> > import matplotlib.backends.backend_cairo as be_cairo
> > AttributeError: 'module' object has no attribute 'backends'
>
> The original matplotlib code is correct, you should be editing IPython
> and correcting their bug!
Well, I'd be delighted to correct the ipython bug, if only I
understood exactly what the problem was... As far as I can see, that
code in ipython is simply calling
 # Initialize matplotlib to interactive mode always
 import matplotlib
 from matplotlib import backends
inside a function (the _matplotlib_config method). I don't see a bug
in that, but if you provide some pointers, I'll be happy to fix any
issues that are on ipython's side of the fence.
Cheers,
f

On Wed, 2007年01月10日 at 11:55 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> Matplotlib does use a lot of relative imports which I think
> Steve> is bad style.
> 
> Steve> See PEP 8 "Style Guide for Python Code"
> Steve> http://www.python.org/dev/peps/pep-0008/
> 
> Steve> - Relative imports for intra-package imports are highly
> Steve> discouraged. Always use the absolute package path for all
> Steve> imports. Even now that PEP 328 [7] is fully implemented in
> Steve> Python 2.5, its style of explicit relative imports is
> Steve> actively discouraged; absolute imports are more portable
> Steve> and usually more readable.
> 
> I have never run into a problem with relative imports, though I don't
> object to removing them. Why are they bad style and what is the danger?
Its because you can unwittingly end up with module name clashes. There
can be two different modules in two different directories with the same
name and you import the wrong module by mistake. It happened to me once
when I created a 'calendar.py' module and didn't realize that Python
already has a calendar module. Its hard to debug because you get a
traceback which makes no sense.
>From PEP328
http://www.python.org/dev/peps/pep-0328/
Rationale for Absolute Imports
In Python 2.4 and earlier, if you're reading a module located inside a
package, it is not clear whether
import foo
refers to a top-level module or to another module inside the package. As
Python's library expands, more and more existing package internal
modules suddenly shadow standard library modules by accident. It's a
particularly difficult problem inside packages because there's no way to
specify which module is meant. To resolve the ambiguity, it is proposed
that foo will always be a module or package reachable from sys.path.
This is called an absolute import.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com