matplotlib-devel Mailing List for matplotlib

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I've updated backend_gtk.py in cvs to use a default
 Steve> exception handler, and noticed a few things in the process:
 Steve> - sys.excepthook does not catch SystemExit, which is what
 Steve> we wanted anyway.
For some reason with matplotlib CVS using backend GTK on linux, I no
longer recover the linux shell when I close the figure by clicking on
the 'x' in the figure window
 > python somefile.py
I have to use CTRL-C.

Hello,
On Tue, Nov 23, 2004 at 03:38:57PM -0600, John Hunter wrote:
> Perhaps I'm missing the obvious thing and not understanding your
> suggestion. But form my end at the level of the matlab interface, the
> best we can do is get a helpful, descriptive error message to the
> user. Did you have another approach in mind?
No, I am not very clear about anything here and was just
throwing ideas around. Actually I am happy with the plans
as far as the PostScript backend is concerned (reporting everyting
as exceptions etc.) So let's just try what you suggested.
All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> I think we should somehow explicitely catch all exceptions
 Jochen> we are expecting (maybe near the main loop) and the
 Jochen> exception handler could feed them to the backend.
 Jochen> Reasons:
 Jochen> 1) This looks like the most Pythonic solution to me:
 Jochen> exceptions are ment to by caught by "try: ... except: ..."
 Jochen> statements
 Jochen> 2) This might open a way to differentiate between expected
 Jochen> exections (opening a file with a user-supplied file name
 Jochen> might fail, if the user mistyped the name -> User should
 Jochen> be told and asked for another file name) and unexpected
 Jochen> ones which indicate programming errors.
 Jochen> 3) Easier to understand flow of control. If you follow a
 Jochen> chain of callers through the source code you can see which
 Jochen> exections are caught at which place, whereas the
 Jochen> except_hook mechanism is more "magical".
 Jochen> What do you think?
I think in the backend and other matplotlib code where we know how to
handle the exception, this makes sense. Eg, if backend_gtk gets a
IOError on some file, it can catch it and request a new filename. We
should catch and handle exceptions where we can.
Buy I'm thinking about the matlab interface. There are two problems
in matlab.py: 1) There are practically no exceptions that we can
handle at that level so the best we can do it forward it on the user
and 2) there is no single point to plug in a master exception handler.
Consider the canonical matlab interface function
def plot(*args, **kwargs):
 ret = gca().plot(*args, **kwargs)
 draw_if_interactive()
gca().plot makes a series of deeply nested calls, as does
draw_if_interactive. With these two calls, a substantial number of
the total methods defined in matplotlib are actually called (format
string parsers, line instantiation, transformations, clipping, gcs,
renderers, font finding, etc, etc....) There are a lot of potential
exceptions to be thrown, and tracking down all of them would be a big
task. And then once we catch them what could we do with them? 
The problem is compounded by the fact that the solution would have to
repeated for *every* matlab interface function separately, which looks
like it would lead to a big tangle of unmanageable code across the
whole module.
Perhaps I'm missing the obvious thing and not understanding your
suggestion. But form my end at the level of the matlab interface, the
best we can do is get a helpful, descriptive error message to the
user. Did you have another approach in mind?
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I've updated backend_gtk.py in cvs to use a default
 Steve> exception handler, and noticed a few things in the process:
 Steve> - sys.excepthook does not catch SystemExit, which is what
 Steve> we wanted anyway.
I think the full exception should be printed. It makes debugging very
hard, otherwise. In fact, while recently debugging some code, I
commented out the exception handler for this reason. matplotlib.cbook
provides a method exception_to_str to convert a traceback to a string.
 Steve> - for some errors I needed to display a matplotlib message
 Steve> rather than the default exception message, or to raise an
 Steve> exception where error_msg () was used with no exception. I
 Steve> added an 'MPLError' exception, its probably best to move it
 Steve> into a central file if other people need to use it also.
Perhaps in matplotlib.__init__ ? 
 Steve> - changing from error_msg() to raise exception means the
 Steve> rest of the method will not execute, which I hadn't thought
 Steve> about. This is no good for 'get_filename_from_user()' where
 Steve> I want to loop until a file (or Cancel) is selected. So I
 Steve> think GTK still has a need to use of a popup message dialog
 Steve> occasionally. And for print_figure() it means the section
 Steve> of code to restore figure settings will not get executed
 Steve> after an error.
I agree that a general facility to popup a message is useful How
abouts we follow Jochen's suggestion and make is a FigureManager
method?
As for your get_filename / restore figure problems, can't these be
addressed by try/catching the exceptions locally, and restoring the
figure state before forwarding the exception onwards?
JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Quick heads-up:
 Fernando> Python 2.2 dicts do NOT have a pop() method, this
 Fernando> appeared in python 2.3. It's fine if you decide to make
 Fernando> matplotlib fully 2.3-dependent, but I just wanted to
 Fernando> make you at least aware of this fact. 2.2 is still in
 Fernando> reasonably wide use in the field, so if you are going to
 Fernando> drop support for it, you might want to put a big fat
 Fernando> warning about this fact, just to save users the hassle
 Fernando> of weird bugs.
Ahh, thanks for your vigilance. I do plan to continue to support 2.2
as long as possible, except for the known issues: datetime and
mathtext. I reverted all the pops to gets. I also made some
enhancements to backend_driver to better work with python2.2 - it now
takes the python to run as a parameter and skips tests where 2.2 is
already known to fail.
Hopefully, I'll remember to be vigilant to test 2.2 before each
release.
JDH

John Hunter schrieb:
>>>>>>"Norbert" == Norbert Nemec <Nor...@gm...> writes:
> 
> 
> Norbert> Hi there, again a few patches, mostly independent but
> Norbert> somewhat interconnected:
> 
> Hi Norbert, thanks for the patches. I applied these, but used a
> somewhat different strategy for legend kwargs. Details below.
> 
> Norbert> axes-kwargs: a general cleanup of the code in axes.py -
> Norbert> in several places, kwargs was handled inconsistently,
> Norbert> ignoring surplus arguments. I went through all uses of
> Norbert> kwargs and made sure that every argument is either used
> Norbert> or reported as error
> 
> There was a bug in the pcolor patch of the axes kwargs
> 
> alpha = kwargs.pop('alpha', 1.0)
> norm = kwargs.pop('norm')
> cmap = kwargs.pop('cmap') 
> vmin = kwargs.pop('vmin')
> vmax = kwargs.pop('vmax') 
> 
> pop doesn't return a default value like get does, so if you want to
> default to None (which we do here) you must explicitly return it
> 
> norm = kwargs.pop('norm', None)
> cmap = kwargs.pop('cmap', None) 
> 
> ...etc...
Quick heads-up:
planck[~]> ip
Python 2.3.3 (#1, May 7 2004, 10:31:40)
Type "copyright", "credits" or "license" for more information.
IPython 0.6.5.cvs -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: a={1:2,3:4}
In [2]: a.p
a.pop a.popitem
BUT (note python version number below):
haar[~]> ip
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
Type "copyright", "credits" or "license" for more information.
IPython 0.6.5.cvs -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: a={1:2,3:4}
In [2]: a.popitem
Python 2.2 dicts do NOT have a pop() method, this appeared in python 2.3. 
It's fine if you decide to make matplotlib fully 2.3-dependent, but I just 
wanted to make you at least aware of this fact. 2.2 is still in reasonably 
wide use in the field, so if you are going to drop support for it, you might 
want to put a big fat warning about this fact, just to save users the hassle 
of weird bugs.
Best,
f

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> Hi there, again a few patches, mostly independent but
 Norbert> somewhat interconnected:
Hi Norbert, thanks for the patches. I applied these, but used a
somewhat different strategy for legend kwargs. Details below.
 Norbert> axes-kwargs: a general cleanup of the code in axes.py -
 Norbert> in several places, kwargs was handled inconsistently,
 Norbert> ignoring surplus arguments. I went through all uses of
 Norbert> kwargs and made sure that every argument is either used
 Norbert> or reported as error
There was a bug in the pcolor patch of the axes kwargs
 alpha = kwargs.pop('alpha', 1.0)
 norm = kwargs.pop('norm')
 cmap = kwargs.pop('cmap') 
 vmin = kwargs.pop('vmin')
 vmax = kwargs.pop('vmax') 
pop doesn't return a default value like get does, so if you want to
default to None (which we do here) you must explicitly return it
 norm = kwargs.pop('norm', None)
 cmap = kwargs.pop('cmap', None) 
 ...etc...
I only caught this bug when I ran examples/backend_driver.py, which
runs many test scripts across many backends, and it is good to make
sure you can run this w/o errors after any non-trivial patch. Just
wanted to make you aware of it.
 Norbert> legend-fontsize: a tiny hack to make Legend respect the
 Norbert> FONTSIZE parameter correctly. (up to now, it was plainly
 Norbert> ignored)
 Norbert> legend-kwargs: have Legend.__init__ respect a bunch of
 Norbert> kwargs, overriding the global defaults. Also Axes.legend
 Norbert> passes these arguments through correctly
For kwargs, my general approach is to make them explicit in their
final target, eg in this case Legend.__init__. So rather than do
 def __init__(self, parent, handles, labels, loc, isaxes=True, **kwargs):
 Artist.__init__(self)
 if is_string_like(loc) and not self.codes.has_key(loc):
 verbose.report_error('Unrecognized location %s. Falling back on upper right; valid locations are\n%s\t' %(loc, '\n\t'.join(self.codes.keys())))
 if is_string_like(loc): loc = self.codes.get(loc, 1)
 
 self.NUMPOINTS = kwargs.pop('numpoints',self.NUMPOINTS)
 self.FONTSIZE = kwargs.pop('fontsize',self.FONTSIZE)
 self.PAD = kwargs.pop('pad',self.PAD)
 self.LABELSEP = kwargs.pop('labelsep',self.LABELSEP)
 self.HANDLELEN = kwargs.pop('handlelen',self.HANDLELEN)
 self.HANDLETEXTSEP = kwargs.pop('handletextsep',self.HANDLETEXTSEP)
 self.AXESPAD = kwargs.pop('axespad',self.AXESPAD)
 if len(kwargs):
 raise TypeError, 'Unknown argument "%s"'%kwargs.keys()[0]
I think it's better to do make them explicit
 def __init__(self, parent, handles, labels, loc,
 isaxes=True,
 numpoints = 4, # the number of points in the legend line
 prop = FontProperties(size='smaller'),
 pad = 0.2, # the fractional whitespace inside the legend border
 # the following dimensions are in axes coords
 labelsep = 0.005, # the vertical space between the legend entries
 handlelen = 0.05, # the length of the legend lines
 handletextsep = 0.02, # the space between the legend line and legend text
 axespad = 0.02, # the border between the axes and legend edge
 ):
because then it is self documenting in the python doc string and
clearer to someone trying to grok the code.
I use the **kwargs approach in methods that are simple thin wrappers
of the ultimate target, eg Axes.legend and matplotlib.matlab.legend.
So this is the approach I took in CVS. I also think I fixed the
fontsize default property issue with the use of prop as a kwarg.
Give it a test drive, and thanks for the patches!
JDH

Hello John,
On Mon, Nov 22, 2004 at 04:50:10PM -0600, John Hunter wrote:
> So what is the canonical way to funnel exceptions into GUI dialog
> boxes? Isn't this what sys.except_hook is for?
I think we should somehow explicitely catch all exceptions
we are expecting (maybe near the main loop) and the exception handler
could feed them to the backend.
Reasons:
1) This looks like the most Pythonic solution to me: exceptions
 are ment to by caught by "try: ... except: ..." statements
2) This might open a way to differentiate between expected exections
 (opening a file with a user-supplied file name might fail, if the
 user mistyped the name -> User should be told and asked for another
 file name) and unexpected ones which indicate programming errors.
3) Easier to understand flow of control. If you follow a chain of callers
 through the source code you can see which exections are caught at which
 place, whereas the except_hook mechanism is more "magical".
What do you think?
Jochen
--=20
http://seehuhn.de/

I've updated backend_gtk.py in cvs to use a default exception handler,
and noticed a few things in the process:
 - sys.excepthook does not catch SystemExit, which is what we wanted
anyway.
 - for some errors I needed to display a matplotlib message rather than
the default exception message, or to raise an exception where error_msg
() was used with no exception. I added an 'MPLError' exception, its
probably best to move it into a central file if other people need to use
it also.
 - changing from error_msg() to raise exception means the rest of the
method will not execute, which I hadn't thought about. This is no good
for 'get_filename_from_user()' where I want to loop until a file (or
Cancel) is selected. So I think GTK still has a need to use of a popup
message dialog occasionally.
And for print_figure() it means the section of code to restore figure
settings will not get executed after an error.
Steve