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