How to remove warnings in PyPlot

322 views
Skip to first unread message

Daniel Carrera

unread,
Nov 1, 2014, 8:52:09 AM11/1/14
to julia...@googlegroups.com
Hello,

I use PyPlot. Whenever I close a window I get a message like,

julia> /usr/lib/pymodules/python2.7/matplotlib/backends/backend_gtk.py:250: Warning: Source ID 714 was not found when attempting to remove it
  gobject.source_remove(self._idle_event_id)


These are harmless, but annoying. Can anyone suggest a way to eliminate these warnings? There must be a reasonable way to close a plot window that won't produce error messages on the console.

Cheers,
Daniel.

Stefan Karpinski

unread,
Nov 1, 2014, 11:40:56 AM11/1/14
to Julia Users
Does this happen with matplotlib by itself?

Daniel Carrera

unread,
Nov 1, 2014, 2:18:17 PM11/1/14
to julia...@googlegroups.com
AFAICT, this does not happen with matplotlib on its own:

% python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
>>> import numpy as np
>>> 0
>>> x = np.array([1,2,3])
>>> plt.plot(x,x)
[<matplotlib.lines.Line2D object at 0x7f3dcef24710>]
>>>
>>> plt.show()
>>>


When I close the Matplotlib window I just get the ">>>" prompt without error.

Cheers,
Daniel.
--
When an engineer says that something can't be done, it's a code phrase that means it's not fun to do.

Steven G. Johnson

unread,
Nov 4, 2014, 11:41:26 PM11/4/14
to julia...@googlegroups.com


On Saturday, November 1, 2014 2:18:17 PM UTC-4, Daniel Carrera wrote:
AFAICT, this does not happen with matplotlib on its own:

It could be that matplotlib is using a different (non-Gtk) backend in Python...

Daniel Carrera

unread,
Nov 5, 2014, 2:28:06 AM11/5/14
to julia...@googlegroups.com
Thanks. Is there a way I could determine if the backend is different?

I just tested a simple plot in Python and Julia. The windows do look very slightly different. It's minor, but on Python the buttons in the plot window have a thin frame around them (so they look more like buttons) and in Julia they do not. That could indicate a different backend. But it would be nice to confirm.

While doing this, I was reminded of a weird quirk of PyPlot that I was hoping you might fix:

julia> using PyPlot
INFO: Loading help data...

julia> x = [1 2 3];

julia> plot(x,x)

This gives an empty plot because "x" has the wrong shape. I spent a while debugging before I remembered. Would it be difficult to change the plot function so that it transposes arrays when needed?

Cheers,
Daniel.


Steven G. Johnson

unread,
Nov 5, 2014, 11:14:19 AM11/5/14
to julia...@googlegroups.com


On Wednesday, November 5, 2014 2:28:06 AM UTC-5, Daniel Carrera wrote:
Thanks. Is there a way I could determine if the backend is different?

I just tested a simple plot in Python and Julia. The windows do look very slightly different. It's minor, but on Python the buttons in the plot window have a thin frame around them (so they look more like buttons) and in Julia they do not. That could indicate a different backend. But it would be nice to confirm.

You can run PyPlot.backend in PyPlot to get the current backend in Julia.  In Python you can do matplotlib.get_backend()
 
julia> x = [1 2 3];

julia> plot(x,x)

This gives an empty plot because "x" has the wrong shape. I spent a while debugging before I remembered. Would it be difficult to change the plot function so that it transposes arrays when needed?

It would not be difficult, but this seems like something that should be changed in Matplotlib.

Daniel Carrera

unread,
Nov 6, 2014, 3:35:28 AM11/6/14
to julia...@googlegroups.com
On 5 November 2014 17:14, Steven G. Johnson <steve...@gmail.com> wrote:

You can run PyPlot.backend in PyPlot to get the current backend in Julia.  In Python you can do matplotlib.get_backend()


Thanks. Python is using TkAgg and while PyPlot is using GTKAgg. What is the recommended fix for this? I can hack PyPlot.jl but I figure that my changes will go away next time I update... Hmm... PyPlot.jl does not include the Tak backend... But it does have the Qt backend, and that one is available...


Alright. I "fixed" my problem by editing PyPlot.jl to make it look for :qt before :gtk under Linux. But this is not ideal because it will revert back next time I upgrade PyPlot. So a more permanent solution is preferable.

 
julia> x = [1 2 3];

julia> plot(x,x)

This gives an empty plot because "x" has the wrong shape. I spent a while debugging before I remembered. Would it be difficult to change the plot function so that it transposes arrays when needed?

It would not be difficult, but this seems like something that should be changed in Matplotlib.


It wouldn't be the first time that PyPlot improves on the Matplotlib API. One of the things I like about PyPlot is that I feel it gives me the simple API that Matplotlib should have given me but didn't. Just my $0.02

Cheers,
Daniel.

Steven G. Johnson

unread,
Nov 6, 2014, 10:45:16 AM11/6/14
to julia...@googlegroups.com
On Thursday, November 6, 2014 3:35:28 AM UTC-5, Daniel Carrera wrote:
Alright. I "fixed" my problem by editing PyPlot.jl to make it look for :qt before :gtk under Linux. But this is not ideal because it will revert back next time I upgrade PyPlot. So a more permanent solution is preferable.

The ideal thing would be to fix
so that you can use the same setting to change the default backend in both Python and Julia.

(Should be possible to support the Tk backend too.)
 
It wouldn't be the first time that PyPlot improves on the Matplotlib API. One of the things I like about PyPlot is that I feel it gives me the simple API that Matplotlib should have given me but didn't. Just my $0.02

Fair enough; in general, I have found Matplotlib to be frustratingly inconsistent about treatment of row vs. column vectors, especially in the contour/pcolor/3d plots.  Could you file an issue?

Daniel Carrera

unread,
Nov 6, 2014, 11:27:55 AM11/6/14
to julia...@googlegroups.com
On 6 November 2014 16:45, Steven G. Johnson <steve...@gmail.com> wrote:
The ideal thing would be to fix
so that you can use the same setting to change the default backend in both Python and Julia.

I just posted to the issue. I must be missing something but now that PyDict(matplotlib["rcParams"])["backend"] works, the fix looks easy.

 
(Should be possible to support the Tk backend too.)

That would be great.

  
It wouldn't be the first time that PyPlot improves on the Matplotlib API. One of the things I like about PyPlot is that I feel it gives me the simple API that Matplotlib should have given me but didn't. Just my $0.02

Fair enough; in general, I have found Matplotlib to be frustratingly inconsistent about treatment of row vs. column vectors, especially in the contour/pcolor/3d plots.  Could you file an issue?

Jean-Francois Moulin

unread,
Nov 6, 2014, 11:30:13 AM11/6/14
to julia...@googlegroups.com
> Daniel.-- When an engineer says that something can't be done, it's a code
phrase that means it's not fun to do.
>
>

Hi!

I used to suffer from the same bug and temporarilly redirected stderr to
/dev/null during the corresponding pyplot call. Now I enjoy clean output again!


here is a patch for
/usr/local/lib/python2.7/dist-packages/matplotlib-1.4.2-py2.7-linux-

x86_64.egg/matplotlib/backends/backend_gtk.py


(path and version of backend_gtk may differ)

---
/usr/local/lib/python2.7/dist-packages/matplotlib-1.4.2-py2.7-linux

x86_64.egg/matplotlib/backends/backend_gtk.py
2014-11-06 17:11:10.634287830 +0100
+++ trick 2014-11-06 17:09:36.802288505 +0100
@@ -250,9 +250,13 @@
def destroy(self):
#gtk.DrawingArea.destroy(self)
self.close_event()
+ # a redirection hack to block the glib warnings! JFM Nov 6 2014
+ temp = sys.stderr
+ sys.stderr = open('/dev/null','w')
gobject.source_remove(self._idle_event_id)
if self._idle_draw_id != 0:
gobject.source_remove(self._idle_draw_id)
+ sys.stderr = temp

def scroll_event(self, widget, event):
if _debug: print('FigureCanvasGTK.%s' % fn_name())


!! some lines had to be broken to be shorter than 80 chars... but you should
get the idea

JF

Reply all
Reply to author
Forward
0 new messages