matplotlib-devel Mailing List for matplotlib

Hi there,

seems like we are synchronizing rather badly in our work and our messages to 
the list. :-)

> Before we reapply your patch to raise on bad kwargs, I think it's
> worth getting some input if we want to raise on nonexistent keys...

Ok, there's a point. I did not even think that there would be any controversy, 
but what you point out should certainly be considered.

Basically, this is a question about the philosophy of properties in general: 
Should properties be settable just per-object, or should settings be 
propagated to the children. I believe the current state is not fully 
consistent in that respect.

What you are proposing is an interesting idea, but if it is adopted, it should 
be done in general and not only in certain places. And in that case, it might 
become rather complex. Properties would have to be uniquely identifiable by 
name only. (I.e. all linewidths have to be called just "linewidth", so an 
object that contains different lines that should be configurable 
independently have to be split in separate sub-objects) The passing of 
properties should happen everywhere in the library - otherwise it will be 
more confusing than helpful.

Currently, it seems to me that there is a rather weak distinction between 
properties and just plain kwargs. This should probably be sorted out before 
adopting a policy of passing all kwargs on to the children.

And as for silently ignoring unknown arguments: I still do not really like 
that idea. It smells like a source of hard to find bugs.

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

Hello,

I'm a happy user of matplotlib. I have both a usage question and a more=20
developer oriented question. First the usage question. I have some=20
trouble using the polarplot. I routinely need to plot complex valued=20
data on a polar grid. But it seems the polar plot requires an extra step=20
where I have to compute the magnitude and phase of my data. Is there an=20
easy way around this?

I would like to develop and contribute a smithchart plot routine but I'm=20
not sure what the best way would be to integrate it into=20
matplotlib.matlab. I understand I would need to create a subclass of=20
Axes for the grid but how is this then integrated into the matlab.axes=20
command? A plotsmithchart command should definately understand complex=20
valued data.
A smithchart grid contains a lot of arcs, looking at how the grid is=20
implemented in PolarAxes it seems there are no circle or arc primitives.=20
Is this correct?

for a brief introduction to the smith chart see:
http://en.wikipedia.org/wiki/Smith_chart

Best regards,
J=F6rgen Stenarson

Hi there,

after the mess I created by submitting those patches using dict.pop (which is 
not available in Python 2.2) here is a patch that hopefully solves the 
problems:

As I found out, cbook.py already contained a routine popd which is supposed to 
be a replacement for dict.pop, which is missing in Python2.2. This new patch 
now reverts to my original kwargs-cleanup-patch but replaces pop by popd

The code runs through examples/backend_driver.py (except for some unrelated 
issue in the PS backend which I do not have the time to debug right now)

B.t.w: In axes.py, line 1461, the CVS version contains a typo "gry" instead of 
"get" which is also fixed by this patch.

Ciao,
Nobbi


-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

On Wed, 2004-11-24 at 09:34 -0600, John Hunter wrote:
> For one thing, cxx strangely doesn't define an IOError.  I don't know
> if this is simply an oversight.  Perhaps I'll file a bug on the sf
> site....
The Python C API uses 
PyErr_SetFromErrnoWithFilename(PyObject *type, char *filename)
to raise IOError exceptions, perhaps cxx has an equivalent function.

Steve

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> Ouch, sorry, I do not even have 2.2 installed. Guess with
    Norbert> that information, the whole patch becomes bogus.

    Norbert> On the other hand: simpy reverting pop to get leaves you
    Norbert> with the old problem: you have to drop the check for
    Norbert> emptyness of kwargs since legal arguments are not removed
    Norbert> after use. If, on the other hand, you remove this check,
    Norbert> erraneous (p.e. misspelled) arguments are just silently
    Norbert> ignored.

    Norbert> Maybe, a wrapper would solve the problem? How would one
    Norbert> code a replacement for pop that works on 2.2 as well?
    Norbert> Probably easiest by using get and del within a
    Norbert> try..except block? The wrapper could then have a clear
    Norbert> note how to replace it once 2.3 becomes mandatory
    Norbert> sometimes in the future.

I added a method popd to matplotlib.cbook.  It should work just like
d.pop(key) but you call popd(d, key).  Like pop, it accepts a default
value.

Before we reapply your patch to raise on bad kwargs, I think it's
worth getting some input if we want to raise on nonexistent keys.  In
some cases, it might be desirable to be able to do, for example

  legend(handles, labels, linewidth=2, fontsize=12)

From an implementation standpoint, it's easiest to implement something
like this using anonymous **kwargs, and iterate over all the handles
and text objects calling set_someprop(val) if set_someprop exists for
some object.

Ie, rather than making all the keyword args explicit and therefore
having to add explicitly add all the setters for line, text and patch
to the kwargs of Legend, which would become a maintenance problem
(duplication of properties throughout the code), one possible design
is to just put a blanket kwargs at the end and define an Artist update
method to look like (freestyle coding here...)

def update(self, **kwargs):
    for key, val in kwargs.items():
        func = getattr(self, 'set_'+key, None)
        if func is None or not callable(func): continue
        func(val)
        

Then we could do in the legend class

   for o in lines+texts+patches: o.update(kwargs)

The downside of course is that this fails silently if the user
provides a bad kwarg.  The upside is it is a very easy, clean
implementation that scales with the addition of new setters to the
underlying objects.


JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
    Steve> For an IOError the exception attribute 'filename' is set to
    Steve> the filename. With your example above
    Steve> self.renderer._renderer.write_png(str (filename)) is Agg
    Steve> C++ extension code The line fp = fopen(file_name, "wb");
    Steve> could be changed to something like if ((fp =
    Steve> fopen(file_name, "wb")) == NULL) throw Py::IOError("could
    Steve> not open file", filename);

    Steve> Does this look right John?

Right in principle, but not in practice.

For one thing, cxx strangely doesn't define an IOError.  I don't know
if this is simply an oversight.  Perhaps I'll file a bug on the sf
site....

The larger problem is that the exception constructor doesn't accept
multiple args and concatenate them.  It would be nice if it did.

I added a Printf class to mplutils to ease the burden of making printf
style strings in C++ to make better exceptions, and updated the
exceptions in the image, agg and ft2font extensions.  The standard
usage is

    if ((fp = fopen(file_name, "wb")) == NULL) 
      throw Py::RuntimeError( Printf("Could not open file %s", file_name).str() );

JDH

On Wed, 2004-11-24 at 12:06 +0000, Jochen Voss wrote:
> Hello,
> 
> On Fri, Nov 19, 2004 at 10:33:43AM -0600, John Hunter wrote:
> > >>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
> >     Jochen> Slight problem: it might now be a little bit more
> >     Jochen> difficult to include the name of the file which could not
> >     Jochen> be opened in the error message.  The IOError exception
> >     Jochen> will probably only have "permission denied" associated
> >     Jochen> with it.
> > 
> > Looks OK, at least on linux
> > 
> > 
> > >>> file('/sbin/ldconfig', 'w')
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > IOError: [Errno 13] Permission denied: '/sbin/ldconfig'
> 
> But sometimes it doesn't give the file name:
> 
>     >>> from matplotlib.matlab import *
>     >>> plot([1,2,3],[2,3,1])
>     [<matplotlib.lines.Line2D instance at 0x41ef774c>]
>     >>> savefig("/forbidden.png")
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>       File ".../matlab.py", line 1009, in savefig
>         manager.canvas.print_figure(*args, **kwargs)
>       File ".../backends/backend_gtkagg.py", line 69, in print_figure
>         agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
>       File ".../backends/backend_agg.py", line 379, in print_figure
>         self.renderer._renderer.write_png(str(filename))
>     RuntimeError: could not open file
> 
> I did not investigate what happens here, but if there is an easy way to
> get the file name into the exception we should probably use it.
> 
> All the best,
> Jochen
For an IOError the exception attribute 'filename' is set to the
filename. With your example above self.renderer._renderer.write_png(str
(filename)) is Agg C++ extension code
The line
 fp = fopen(file_name, "wb");
could be changed to something like
 if ((fp = fopen(file_name, "wb")) == NULL)
     throw Py::IOError("could not open file", filename);

Does this look right John?

Steve

On Tue, 2004-11-23 at 16:38 -0600, John Hunter wrote:
> >>>>> "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.
> 
This situation happens when the main window is destroyed but
gtk.main_quit() is not called - the gtk.main loop is still running.
I'm not seeing this problem at the moment.

In FigureManagerGTK the 'destroy' signal is connected to Gcf.destroy
(num), which should eventually call

class FigureManagerGTK
    def destroy(self, *args):
        self.window.destroy()
        if Gcf.get_num_fig_managers()==0 and not
matplotlib.is_interactive():
            gtk.main_quit()

I set DEBUG = True and ran a few examples and it showed
FigureManagerGTK.destroy() was being called as expected.
Perhaps Gcf.get_num_fig_managers() is sometimes not 0 when it should be
0 and gtk.main_quit() is not being called.

Steve

Hello,

On Fri, Nov 19, 2004 at 10:33:43AM -0600, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
>     Jochen> Slight problem: it might now be a little bit more
>     Jochen> difficult to include the name of the file which could not
>     Jochen> be opened in the error message.  The IOError exception
>     Jochen> will probably only have "permission denied" associated
>     Jochen> with it.
>=20
> Looks OK, at least on linux
>=20
>=20
> >>> file('/sbin/ldconfig', 'w')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> IOError: [Errno 13] Permission denied: '/sbin/ldconfig'

But sometimes it doesn't give the file name:

    >>> from matplotlib.matlab import *
    >>> plot([1,2,3],[2,3,1])
    [<matplotlib.lines.Line2D instance at 0x41ef774c>]
    >>> savefig("/forbidden.png")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File ".../matlab.py", line 1009, in savefig
        manager.canvas.print_figure(*args, **kwargs)
      File ".../backends/backend_gtkagg.py", line 69, in print_figure
        agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
      File ".../backends/backend_agg.py", line 379, in print_figure
        self.renderer._renderer.write_png(str(filename))
    RuntimeError: could not open file

I did not investigate what happens here, but if there is an easy way to
get the file name into the exception we should probably use it.

All the best,
Jochen
--=20
http://seehuhn.de/

Am Dienstag, 23. November 2004 22:07 schrieb John Hunter:
> >>>>> "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.

Ouch, sorry, I do not even have 2.2 installed. Guess with that information, 
the whole patch becomes bogus.

On the other hand: simpy reverting pop to get leaves you with the old problem: 
you have to drop the check for emptyness of kwargs since legal arguments are 
not removed after use. If, on the other hand, you remove this check, 
erraneous (p.e. misspelled) arguments are just silently ignored.

Maybe, a wrapper would solve the problem? How would one code a replacement for 
pop that works on 2.2 as well? Probably easiest by using get and del within a 
try..except block? The wrapper could then have a clear note how to replace it 
once 2.3 becomes mandatory sometimes in the future.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

On Tue, 2004-11-23 at 15:28 -0600, John Hunter wrote:
>     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__ ?  
OK, I've added "MPLError' a subclass of Exception to matplotlib.__init__

Steve

>>>>> "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

John Hunter schrieb:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     >> overridden.  I don't see any elegant way to do this.  Any
>     >> ideas?
> 
>     Fernando> In [2]: sys.__excepthook__ is sys.excepthook Out[2]:
> 
> Excellent.  So if the backends define a function excepthook_backend
> and matplotlib.matlab does
> 
> if sys.__excepthook__ is sys.excepthook:
>     sys.excepthook = excepthook_backend
> 
> would we be in reasonably good standing with the python gods and
> others?

You'd have to ask the gods directly, but it looks pretty good to me, a mere 
mortal :)

Best,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    >> overridden.  I don't see any elegant way to do this.  Any
    >> ideas?

    Fernando> In [2]: sys.__excepthook__ is sys.excepthook Out[2]:

Excellent.  So if the backends define a function excepthook_backend
and matplotlib.matlab does

if sys.__excepthook__ is sys.excepthook:
    sys.excepthook = excepthook_backend

would we be in reasonably good standing with the python gods and
others?

JDH

John Hunter schrieb:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     >> Actually, it would be fine if matplotlib overrode
>     >> sys.except_hook and ipython later came along and overrode that.
>     >> Basically, ipython would be saying, "I know I've got a shell to
>     >> display errors in, so we don't need to GUI method".  I don't
>     >> think matplotlib would have a problem with that.  Ditto for
>     >> envisage.  Basically, we would be providing a default method to
>     >> get the message to the GUI which could be overriden by other
>     >> applications that want to (ipython, envisage, what-have-you).
> 
>     Fernando> I guess this is a good heads-up for me.  I know ipython
>     Fernando> does some of this, I'll just add a bit more such
>     Fernando> control.  That way, if during the running of user code
>     Fernando> they need sys.ehook for something, they'll get it.  But
>     Fernando> ipython will keep it for when it needs it.  I'm pretty
>     Fernando> sure the embeddable ipython has such control in it, I
>     Fernando> may just need to put it in the general case as well.
> 
>     Fernando> Ultimately I'm not 100% sure what a good solution for
>     Fernando> matplotlib is, I just wanted to make you aware of these
>     Fernando> issues, so that at least they are on your radar.
> 
> 
> We do have some more options.  For one, we could use the excepthook
> only in the matlab interface -- in this case matlab is being used more
> as an application rather than a library.  Folks using matplotlib as a
> library, eg embedding in a GUI, would be advised to do their own
> trapping.
> 
> The only exceptional case I see is basically the ipython (and friends)
> case.  Ie, someone wants to write a shell or otherwise that embeds
> matplotlib.matlab.  In this case it would be fine to override
> matplotlib.matlab's excepthook, as discussed.
> 
> To play really nicely, matplotlib.matlab would like to be able to
> override excepthook only if it hadn't been otherwise overridden.  I
> don't see any elegant way to do this.  Any ideas?

Yup:

planck[mayavi]> ip
In [1]: import sys

In [2]: sys.__excepthook__ is sys.excepthook
Out[2]: False

planck[mayavi]> python
 >>> import sys
 >>> sys.__excepthook__ is sys.excepthook
True

Cheers,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    >> Actually, it would be fine if matplotlib overrode
    >> sys.except_hook and ipython later came along and overrode that.
    >> Basically, ipython would be saying, "I know I've got a shell to
    >> display errors in, so we don't need to GUI method".  I don't
    >> think matplotlib would have a problem with that.  Ditto for
    >> envisage.  Basically, we would be providing a default method to
    >> get the message to the GUI which could be overriden by other
    >> applications that want to (ipython, envisage, what-have-you).

    Fernando> I guess this is a good heads-up for me.  I know ipython
    Fernando> does some of this, I'll just add a bit more such
    Fernando> control.  That way, if during the running of user code
    Fernando> they need sys.ehook for something, they'll get it.  But
    Fernando> ipython will keep it for when it needs it.  I'm pretty
    Fernando> sure the embeddable ipython has such control in it, I
    Fernando> may just need to put it in the general case as well.

    Fernando> Ultimately I'm not 100% sure what a good solution for
    Fernando> matplotlib is, I just wanted to make you aware of these
    Fernando> issues, so that at least they are on your radar.


We do have some more options.  For one, we could use the excepthook
only in the matlab interface -- in this case matlab is being used more
as an application rather than a library.  Folks using matplotlib as a
library, eg embedding in a GUI, would be advised to do their own
trapping.

The only exceptional case I see is basically the ipython (and friends)
case.  Ie, someone wants to write a shell or otherwise that embeds
matplotlib.matlab.  In this case it would be fine to override
matplotlib.matlab's excepthook, as discussed.

To play really nicely, matplotlib.matlab would like to be able to
override excepthook only if it hadn't been otherwise overridden.  I
don't see any elegant way to do this.  Any ideas?

JDH

John Hunter schrieb:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> 
>     Fernando> I realize that excepthook is a tempting tool to use, but
>     Fernando> I hope you guys reconsider this.  I really think it
>     Fernando> would cause many more headaches down the road than those
>     Fernando> it initially appears to solve.
> 
> OK, good to know.  That was news to me.  Now why is it that ipython
> and envisage get to mess around with it and we don't :-) ?
> 
> So what is the canonical way to funnel exceptions into GUI dialog
> boxes?  Isn't this what sys.except_hook is for?

Mmh, I don't really know for sure.  But here's a quick test:

planck[mayavi]> egrep -r sys.except *
planck[mayavi]>

This is on the mayavi sources.  Mayavi DOES show all VTK exceptions into a GUI 
(such as you get when you try to open the volume rendering module with 
floating point data, for example).  I imagine it just traps them locally, but 
I'm not sure.  It is possible that mayavi has an easier job because it's done 
in Tk, with no threading issues to worry about.  Threads make this problem 
MUCH worse, since python has no sensible way for an exception raised in one 
thread to be handled by another: all go to the sys.excepthook bucket.  There 
have been long, complicated threads recently on c.l.py on the cousin topics of 
signals and exceptions in threads, and it doesn't look pretty.

> Actually, it would be fine if matplotlib overrode sys.except_hook and
> ipython later came along and overrode that.  Basically, ipython would
> be saying, "I know I've got a shell to display errors in, so we don't
> need to GUI method".  I don't think matplotlib would have a problem
> with that.  Ditto for envisage.  Basically, we would be providing a
> default method to get the message to the GUI which could be overriden
> by other applications that want to (ipython, envisage, what-have-you).

I guess this is a good heads-up for me.  I know ipython does some of this, 
I'll just add a bit more such control.  That way, if during the running of 
user code they need sys.ehook for something, they'll get it.  But ipython will 
keep it for when it needs it.  I'm pretty sure the embeddable ipython has such 
control in it, I may just need to put it in the general case as well.

Ultimately I'm not 100% sure what a good solution for matplotlib is, I just 
wanted to make you aware of these issues, so that at least they are on your radar.

Best,

f