matplotlib-devel Mailing List for matplotlib (Page 12)

On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <js...@fa...> wrote:
> What do you think? If it's OK I say we use the natgrid package in
> matplotlib, since it's more bulletproof than the scikits package (it passes
> Robert's degenerate triangulation test, and has been pounded on by user of
> NCAR graphics since the 1980's).
Great work! I just contacted Jonathan with a similar query for
Triangle, but am fully expecting a "no way" so very nice work on
natgrid. The licensing terms look fine to me. Just drop the license
in our licenses directory with some suitable name and fire away. Also
make sure the license is included in the module docstring so we comply
with the "redistribution in binary form" clause. In the unlikely
event that Jonathan also comes back to us with a new license, we can
decide then which is the better implementation.
JDH

On Fri, Jul 18, 2008 at 10:14:00AM -0500, John Hunter wrote:
> Basically, you want to support users who are using ipython -wthread
> but not -pylab who later import pylab with a misconfigured rc.
That's ine way of putting it. You are considering the ipython, the way it
is currently implemented is the only entry point to interactiv use of
matplotlib. I think the is about to change significantly with the
introduction of GUI frontends to ipython, that are not inheritely bound
to pylab, like 'ipython -pylab' is. In fact Enthought has very short
terms plans to make an IDE.
> Is this really desirable? Certainly you would want to trap this or
> warn or something so they don't get strange segfaults or other hard to
> diagnose errors, but automagically switching the backend in mpl may be
> too helpful in the way that microsoft windows is occassionally too
> helpful.
You have a point. I agree that my approach is not the good one, and is
forcing too mcuh magic on the user. I will elaborate what might be a
better solution below.
> What about checking to see if your ipython module is in sys.modules
> when pyplot is imported, checking the backend, and then importing it,
> checking for wthread etc, issuing a severe warning with known
> misconfigurations, eg gtkagg, with instructions on how to fix is (eg
> "your matplotlibrc file is here and the backend needs to be set to
> such-and-such...")?
This is not about the wthread option. This is about embedding in a large
GUI, whether it be the IDE I was mentionning, or winpdb, or SPE, or
Mayavi. I don't think the current implementation is acceptable: you are
requiring the users to change the backend depending on the eventloop they
are running. Not only is this tedious, but it also require a fair amount
of technical knowledge and exposes details (kind of event loop) that are
irrelevent to the end user. Finally a lot of people will see the crash,
and simply conclude that matplotib, or the interactive program they are
runnning it from is buggy. We have had this come up more than once on the
enthought-dev mailing list, and I wonder how many people simply never ask.
OK, now what is the way forward. We need to provide the advanced-user for
a good control on the backend. We need to provide a way that simply works
without changing anything. The same code should run in "ipython -pylab",
idle, or SPE. I think this means we need to add an rc entry. We could
have two entries for backends:
backend: auto or any of the current existing
backend-default: any of the current existing
If backend is set to auto, pyplot would check if an event loop is running
and select the appriopriate backend. If no eventloop is running, it would
use the backend specified in backend-default.
This should work fairly nicely. The only think I am worried about is
people changing the backend using matlplotlib.use, while rc['backend'] is
still at auto, and then importing pyplot, which would change again the
backend. Any suggestion for how to address that? Maybe matploib.use could
put a flag somewhere, saying that it has been explicitely called.
Internallythe plyplot magic to choose the backend would not set this
flag.
Comments?
Gaël

Jeff Whitaker wrote:
> John Hunter wrote:
> 
>> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> wrote:
>>
>> 
>> 
>>> I'd like to see griddata functionality and Ryan May's wind barb patch in
>>> 0.98.3.
>>> 
>>> 
>> OK things seem to be moving pretty fast right now on several fronts,
>> so we may want to wait until mid next week before pushing anything
>> out. Robert and I exchanged a few emails last night about his
>> delaunay code. We have two choices on the dependency -- require an
>> external scikits.delaunay that the user will install, or ship it
>> *internally* in matplotlib, eg as matplotlib.delaunay (he is not too
>> keen to see us repeat the mistakes we made with enthought.traits
>> installing it ourselves externally). I prefer the matplotlib.delaunay
>> solution since many win32, os x or naive users will not be comfortable
>> with the svn download and source install.
>>
>> But Robert pointed out to me that one reason he has avoided pushing
>> this further, eg into scipy, is that there are known degenerate cases
>> arising from floating point precision issues that need to be worked
>> out
>>
>> He wrote:
>>
>> My apologies, it does not segfault; it just returns an impossible
>> triangulation.
>>
>> def test_slightly_degenerate(self):
>> data = np.array([[-1, -1], [-1, 0], [-1, 1],
>> [ 0, -1], [ 0, 0], [ 0, 1],
>> [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1],
>> ])
>> tri = dlny.Triangulation(data[:,0], data[:,1])
>>
>>
>> I thought it possible that one of our developers may be interested in
>> working on this, and he gave the following advice:
>>
>> Basically, Fortune's sweepline algorithm for Delaunay triangulation
>> simply needs to be replaced with an algorithm that can be formulated
>> using Jonathan Shewchuck's robust predicates:
>>
>> http://www.cs.cmu.edu/~quake/robust.html
>>
>> Divide and conquer or incremental insertion are reasonable candidates.
>> Personally, I am willing to include the code in its current imperfect
>> form in mpl with your griddata wrapper, provided that we make clear in
>> the docstring that there are known degenerate cases (eg include
>> Robert's example). Caveat emptor: this is an oft requested piece of
>> code and I think many users would like to have something that works in
>> most cases. But I think everyone would be well served by having a
>> bullet-proof algorithm and Robert won't have time to work on this in
>> the upcoming months, so perhaps one of us could spend some time
>> looking at following Robert's suggestion and incorporating Jonathan
>> Shewchuck's robust predicates into the implementation.
>> 
>> 
>
> John: I concur with your plan. The triangulation algorithm used in the 
> natgrid package is quite bulletproof. Unfortunately, it's GPL and I 
> haven't been able to get NCAR to change the license. I checked 
> Shewchuk's web page and unfortunately his code comes with this license:
>
> These programs may be freely redistributed under the condition that the
> copyright notices (including the copy of this notice in the code comments
> and the copyright notice printed when the `-h' switch is selected) are
> not removed, and no compensation is received. Private, research, and
> institutional use is free. You may distribute modified versions of this
> code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT
> IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH
> SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND
> CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. Distribution of this code as
> part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT
> WITH THE AUTHOR. (If you are not directly supplying this code to a
> customer, and you are instead telling them how they can obtain it for
> free, then you are not required to make any arrangement with me.)
>
> which is definitely not acceptable. I'll start to research other 
> options ...
> 
John: I just contacted NCAR again, and it seems that they have 
relicensed the software under an OSI-based license similar to the 
University of Illinois/NCSA:
Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:
 * Neither the names of NCAR's Computational and Information Systems
 Laboratory, the University Corporation for Atmospheric Research,
 nor the names of its contributors may be used to endorse or
 promote products derived from this Software without specific prior
 written permission.
 * Redistributions of source code must retain the above copyright
 notices, this list of conditions, and the disclaimer below.
 * Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions, and the disclaimer below in the
 documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 
IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR 
ANY CLAIM, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 
THE USE OR OTHER DEALINGS WITH THE SOFTWARE.
What do you think? If it's OK I say we use the natgrid package in 
matplotlib, since it's more bulletproof than the scikits package (it 
passes Robert's degenerate triangulation test, and has been pounded on 
by user of NCAR graphics since the 1980's).
-Jeff
> 
>> So my advice is: let's fold the delaunay code into matplotlib.delaunay
>> for 0.98.3 while providing copious warnings in your griddata
>> interface, and get to work improving the algorithm for future
>> releases, making sure we send Robert patches to the scikit.delaunay
>> module if we manage to do anything useful so his implementation will
>> remain the official branch as long as he wants it to be. If everyone
>> agrees with this plan, I'll assume you'll take the lead on importing
>> the code, and providing some examples/tests.
>> 
>> 
>
> OK.
>
> -Jeff
> 
>> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
>>
>> JDH
>> 
>> 
>
>
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Fri, Jul 18, 2008 at 12:01, John Hunter <jd...@gm...> wrote:
> On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> wrote:
>
>> John: I concur with your plan. The triangulation algorithm used in the
>> natgrid package is quite bulletproof. Unfortunately, it's GPL and I haven't
>> been able to get NCAR to change the license. I checked Shewchuk's web page
>> and unfortunately his code comes with this license:
>
> Well there are two parts to his code. His triangulation code license
> is clearly unacceptable, but we could send Fernando over to talk to
> him (since Fernando is now at Berkeley too) about considering a
> license change. But his predicates code for orientation and incircle
> tests is in the public domain
> (http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c).
> I think Robert was referring to incorporating these robust tests into
> his code rather than the actual triangle implementation, but perhaps
> he can clarify.
I meant that a Delaunay triangulation routine can be written using
these public domain robust predicates. The current sweepline algorithm
is not formulated to be able to use these predicates, so a different
algorithm has to be implemented rather than simply incorporating the
predicates into the current code.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco

On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> wrote:
> John: I concur with your plan. The triangulation algorithm used in the
> natgrid package is quite bulletproof. Unfortunately, it's GPL and I haven't
> been able to get NCAR to change the license. I checked Shewchuk's web page
> and unfortunately his code comes with this license:
Well there are two parts to his code. His triangulation code license
is clearly unacceptable, but we could send Fernando over to talk to
him (since Fernando is now at Berkeley too) about considering a
license change. But his predicates code for orientation and incircle
tests is in the public domain
(http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c).
 I think Robert was referring to incorporating these robust tests into
his code rather than the actual triangle implementation, but perhaps
he can clarify.
JDH

John Hunter wrote:
> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> wrote:
>
> 
>> I'd like to see griddata functionality and Ryan May's wind barb patch in
>> 0.98.3.
>> 
>
> OK things seem to be moving pretty fast right now on several fronts,
> so we may want to wait until mid next week before pushing anything
> out. Robert and I exchanged a few emails last night about his
> delaunay code. We have two choices on the dependency -- require an
> external scikits.delaunay that the user will install, or ship it
> *internally* in matplotlib, eg as matplotlib.delaunay (he is not too
> keen to see us repeat the mistakes we made with enthought.traits
> installing it ourselves externally). I prefer the matplotlib.delaunay
> solution since many win32, os x or naive users will not be comfortable
> with the svn download and source install.
>
> But Robert pointed out to me that one reason he has avoided pushing
> this further, eg into scipy, is that there are known degenerate cases
> arising from floating point precision issues that need to be worked
> out
>
> He wrote:
>
> My apologies, it does not segfault; it just returns an impossible
> triangulation.
>
> def test_slightly_degenerate(self):
> data = np.array([[-1, -1], [-1, 0], [-1, 1],
> [ 0, -1], [ 0, 0], [ 0, 1],
> [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1],
> ])
> tri = dlny.Triangulation(data[:,0], data[:,1])
>
>
> I thought it possible that one of our developers may be interested in
> working on this, and he gave the following advice:
>
> Basically, Fortune's sweepline algorithm for Delaunay triangulation
> simply needs to be replaced with an algorithm that can be formulated
> using Jonathan Shewchuck's robust predicates:
>
> http://www.cs.cmu.edu/~quake/robust.html
>
> Divide and conquer or incremental insertion are reasonable candidates.
> Personally, I am willing to include the code in its current imperfect
> form in mpl with your griddata wrapper, provided that we make clear in
> the docstring that there are known degenerate cases (eg include
> Robert's example). Caveat emptor: this is an oft requested piece of
> code and I think many users would like to have something that works in
> most cases. But I think everyone would be well served by having a
> bullet-proof algorithm and Robert won't have time to work on this in
> the upcoming months, so perhaps one of us could spend some time
> looking at following Robert's suggestion and incorporating Jonathan
> Shewchuck's robust predicates into the implementation.
> 
John: I concur with your plan. The triangulation algorithm used in the 
natgrid package is quite bulletproof. Unfortunately, it's GPL and I 
haven't been able to get NCAR to change the license. I checked 
Shewchuk's web page and unfortunately his code comes with this license:
These programs may be freely redistributed under the condition that the
copyright notices (including the copy of this notice in the code comments
and the copyright notice printed when the `-h' switch is selected) are
not removed, and no compensation is received. Private, research, and
institutional use is free. You may distribute modified versions of this
code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT
IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH
SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND
CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. Distribution of this code as
part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT
WITH THE AUTHOR. (If you are not directly supplying this code to a
customer, and you are instead telling them how they can obtain it for
free, then you are not required to make any arrangement with me.)
which is definitely not acceptable. I'll start to research other 
options ...
> So my advice is: let's fold the delaunay code into matplotlib.delaunay
> for 0.98.3 while providing copious warnings in your griddata
> interface, and get to work improving the algorithm for future
> releases, making sure we send Robert patches to the scikit.delaunay
> module if we manage to do anything useful so his implementation will
> remain the official branch as long as he wants it to be. If everyone
> agrees with this plan, I'll assume you'll take the lead on importing
> the code, and providing some examples/tests.
> 
OK.
-Jeff
> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
>
> JDH
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Periodically I go through the developer list and prune developers who
haven't made a commit in the last year, and was just reminded to do
this when I added David. This keeps the developers list down to a
reasonable size and makes it accurately reflect those who are
currently developing mpl. This is just a by-the-numbers decision,
we'd love to have any and all of you back, and I will be happy to
readd anyone who needs or wants to make commits, so just email me.
The user name and last commit date of those removed are listed below:
 edin1 2007年07月16日
 kmcivor 2007年07月06日
 stevech 2007年07月08日
 teoliphant 2007年04月05日
For the record books, here is the script I use to parse the svn logs:
import matplotlib.cbook as cbook
todate = cbook.todate('%Y-%m-%d')
border='------------------------------------------------------------------------'
last = dict()
for commit in file('log.out').read().split(border):
 if not commit.strip():
 continue
 lines = commit.split('\n')
 line = lines[1]
 parts = [p.strip() for p in line.split('|')]
 user = parts[1]
 date = todate(parts[2][:10])
 if user not in last:
 last[user] = date
dsu = [(date, user) for user, date in last.items()]
dsu.sort()
for date, user in dsu:
 print user, date

On Fri, Jul 18, 2008 at 11:27:50AM +0200, David M. Kaplan wrote:
> Hi,
> 
> On Thu, 2008年07月17日 at 16:55 -0400, Paul Kienzle wrote:
> > FigureCanvasBase:
> > def start_event_loop(self, ...): 
> > raise NotImplemented
> > FigureCanvasEventLoopMixin:
> > def start_event_loop(self, ...):
> > generic interactive using time.sleep
> > MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
> > ... no start_event_loop since using the generic mixin ...
> > 
> 
> So just to make sure that I understand this, "MyInteractiveBackend"
> would be any backend canvas class for whom we want to implement the
> standard generic mixin. For example, the class FigureCanvasGTK would
> inherit FigureCanvasEventLoopMixin until we get around to writing
> something specific for GTK. On the other hand, FigureCanvasWx wouldn't
> inherit the mixin, but would use the WX specific code you sent
> yesterday. And FigureCanvasPs wouldn't get anything at all. Am I
> getting this?
Yes.
> If so, then I will go ahead and make the appropriate modifications.
> Looking at the list of backends, I think it suffices to inherit the
> mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk,
> qt4, qt, tkagg (wx covered with its own code). All other interactive
> backends should inherit from these. The ones with the question marks I
> am not really sure about, but will assume true unless told otherwise.
$ grep -l button_press_event backends/*.py
backends/backend_cocoaagg.py
backends/backend_fltkagg.py
backends/backend_gtk.py
backends/backend_qt.py
backends/backend_qt4.py
backends/backend_template.py
backends/backend_tkagg.py
backends/backend_wx.py
> I agree with Gael that warning is probably sufficient. This will allow
> code running in the background to pass over interactive commands such as
> ginput. This may be better than an immediate error, but could cause
> problems later in the script when data is expected, but one gets [].
If exceptions aren't used, then non-interactive backends should
return [], and all calls to ginput should be checked:
 x = ginput(3,timeout=2)
 if len(x) < 3:
 print "ginput only returned %d inputs"%(len(x))
Since users aren't going to remember to do this, it is better to 
raise an exception so that they at least know later why their code 
is breaking.
The current code has another problem in that timeouts will return
a partial list. This could be handle by raising RuntimeError in
ginput:
 class BlockingInput:
 ...
 def __call__(...):
 ...
 if n > 0 and len(self.clicks) < n:
 raise RuntimeError("Timeout when selecting inputs")
 return self.clicks
If you want to get fancy and return the partial list of clicks, 
this can be done with our own exception class:
 --blocking_input.py--
 class InputError(Exception):
 def __init__(self, message, points):
 self.message = message
 self.points = points
 class BlockingInput:
 ...
 def __call__(...):
 ...
 if n > 0 and len(self.clicks) < n:
 raise InputError("Not enough inputs",self.clicks)
 return self.clicks
Importing an extra symbol to catch the error would be ugly. I 
suggest hiding it in the functions that need it instead:
 --pyplot.py--
 def ginput(*args, **kwargs):
 ...
 ginput.InputError = matplotlib.blocking_input.InputError
This allows the pylab user to write:
 try:
 x = ginput(3,timeout=2)
 except ginput.InputError,e:
 print "ginput only returned %d inputs"%(len(e.points))
- Paul

On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> wrote:
> I'd like to see griddata functionality and Ryan May's wind barb patch in
> 0.98.3.
OK things seem to be moving pretty fast right now on several fronts,
so we may want to wait until mid next week before pushing anything
out. Robert and I exchanged a few emails last night about his
delaunay code. We have two choices on the dependency -- require an
external scikits.delaunay that the user will install, or ship it
*internally* in matplotlib, eg as matplotlib.delaunay (he is not too
keen to see us repeat the mistakes we made with enthought.traits
installing it ourselves externally). I prefer the matplotlib.delaunay
solution since many win32, os x or naive users will not be comfortable
with the svn download and source install.
But Robert pointed out to me that one reason he has avoided pushing
this further, eg into scipy, is that there are known degenerate cases
arising from floating point precision issues that need to be worked
out
He wrote:
 My apologies, it does not segfault; it just returns an impossible
triangulation.
 def test_slightly_degenerate(self):
 data = np.array([[-1, -1], [-1, 0], [-1, 1],
 [ 0, -1], [ 0, 0], [ 0, 1],
 [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1],
 ])
 tri = dlny.Triangulation(data[:,0], data[:,1])
I thought it possible that one of our developers may be interested in
working on this, and he gave the following advice:
 Basically, Fortune's sweepline algorithm for Delaunay triangulation
 simply needs to be replaced with an algorithm that can be formulated
 using Jonathan Shewchuck's robust predicates:
 http://www.cs.cmu.edu/~quake/robust.html
 Divide and conquer or incremental insertion are reasonable candidates.
Personally, I am willing to include the code in its current imperfect
form in mpl with your griddata wrapper, provided that we make clear in
the docstring that there are known degenerate cases (eg include
Robert's example). Caveat emptor: this is an oft requested piece of
code and I think many users would like to have something that works in
most cases. But I think everyone would be well served by having a
bullet-proof algorithm and Robert won't have time to work on this in
the upcoming months, so perhaps one of us could spend some time
looking at following Robert's suggestion and incorporating Jonathan
Shewchuck's robust predicates into the implementation.
So my advice is: let's fold the delaunay code into matplotlib.delaunay
for 0.98.3 while providing copious warnings in your griddata
interface, and get to work improving the algorithm for future
releases, making sure we send Robert patches to the scikit.delaunay
module if we manage to do anything useful so his implementation will
remain the official branch as long as he wants it to be. If everyone
agrees with this plan, I'll assume you'll take the lead on importing
the code, and providing some examples/tests.
And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
JDH

On Friday 18 July 2008 11:14:00 am John Hunter wrote:
> On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux
> What about checking to see if your ipython module is in sys.modules
> when pyplot is imported, checking the backend, and then importing it,
> checking for wthread etc, issuing a severe warning with known
> misconfigurations, eg gtkagg, with instructions on how to fix is (eg
> "your matplotlibrc file is here and the backend needs to be set to
> such-and-such...")?
I am more comfortable with this approach.

On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux
<gae...@no...> wrote:
> Hum, maybe I am not understanding properly what you mean here. It acts on
> matplotlib only when it is passed the -pylab argument, AFAIK. Thus if you
OK, at least I understand the issue now a bit better, thanks for
explaining it. But I am not entirely comfortable with the solution.
In general we have avoided trying to magically get stuff right in
favor of making sure people are properly configured. This poses
inconveniences to new users but at least allows people who are clear
in their intentions to get what they want. I worry by forcing the
backend to wx or wxagg just because wx has already been imported we
are making too many assumptions (someone may want to use matplotlib
pyplot in a wx app to generate pure image figures with the ps backend,
etc...). We also now support custom external backends with the
module://some_backend syntax so in principle one could be using a
custom wx backend with a custom renderer outside of mpl.
I'm sure there is a way to get what you want, but this may not be it.
Basically, you want to support users who are using ipython -wthread
but not -pylab who later import pylab with a misconfigured rc. Is
this really desirable? Certainly you would want to trap this or warn
or something so they don't get strange segfaults or other hard to
diagnose errors, but automagically switching the backend in mpl may be
too helpful in the way that microsoft windows is occassionally too
helpful.
What about checking to see if your ipython module is in sys.modules
when pyplot is imported, checking the backend, and then importing it,
checking for wthread etc, issuing a severe warning with known
misconfigurations, eg gtkagg, with instructions on how to fix is (eg
"your matplotlibrc file is here and the backend needs to be set to
such-and-such...")?
JDH

John Hunter wrote:
> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
> 
>> Hi All,
>> I'd like to "resubmit" the request below: any new version to be
>> released soon? in the process to generate the doc in Debian, something
>> got fixed upstream, so a new release would be really helpful to have
>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>> strange chars in it).
>> 
>
> I think we could do a 0.98.3 release. There have been several bugs
> fixed. Could you do me a favor and check svn r5722 and see if it
> meets all your requirements for debian before we actually do the
> release?
>
> Thanks,
> JDH
>
>
> 
I'd like to see griddata functionality and Ryan May's wind barb patch in 
0.98.3.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Fri, Jul 18, 2008 at 9:31 AM, Tuukka Verho <ty...@cc...> wrote:
> It seems that the function getpoints() doesn't take care of the
> situations when the slope of the line (x1,y1,x2,y2) is zero or infinity.
> This could be solved with the simple check in the function:
>
> if y2-y1 == 0:
> return x2, y2+k, x2, y2-k
> elif x2-x1 == 0:
> return x2+k, y2, x2-k, y2
>
> This fixes it for me.
Thanks for the bug report and fix -- I've committed the changes to the
91 branch and the svn trunk.
>
> By the way, I just found out about matplotlib, and I find it extremely
> useful! Thanks to all devs for creating this :).
Glad you're liking it, and thanks for the help!
JDH

On Fri, Jul 18, 2008 at 09:15:16AM -0500, John Hunter wrote:
> ipython Shell.py already hacks wx, gtk, and tk to make sure mpl's
> mainloop is not going to cause any problems (eg
> IPython.Shell.hijack_wx). Is there something about the new ipython wx
> frontend design that requires a different solution for mpl?
Hum, maybe I am not understanding properly what you mean here. It acts on
matplotlib only when it is passed the -pylab argument, AFAIK. Thus if you
load "ipython -wthread" you will still be getting the default backend for
matplotlib if you import it later on, and that default backend is GTK on
Ubuntu, and the GTK mainloop doesn't play well at all with the wx one.
> I'm happy to hold the release until we get this sorted out, but before
> I review the patch maybe you can let me know what if anything is
> different about the new ipython design that requires changes in mpl
> because I haven't followed the ipython redesign closely enough.
The frontend I am talking about is a PyShell replacement. It is a Wx
widget and is not even multithreaded: it lives in the mainloop. We could
indeed load pylab at the start and choose the right backend, but this
requires preloading pylab, and I am not to enthousiastic about such a
potential loss of time at load for users who have not asked for matlab.
We could also provide a "-pylab" switch, but right now we don't even have
a canonical entry point: this is a widget, and not a program. I'll talk
to Fernando to have his view on this.
The patch I have sent would also allow for seemless use of matplotlib in
SPE, winpdb, or Mayavi, as all these apps use the wx mainloop.
I hope this clarifies the situtation.
Cheers,
Gaël

On Fri, Jul 18, 2008 at 3:50 AM, David M. Kaplan <Dav...@ir...> wrote:
>> I would probably write a cbook method is_sequence_of_strings and just
>> call that since it will be more readable and reusable...
>>
>
> Method added to cbook.
This method will return true on a string, which is probably not what you want
 In [46]: is_sequence_of_strings('jdh was here')
 Out[46]: True
My original example included an additional check on is_string_like(obj).
If you want to optionally support a string as a sequence of strings, I
think we might need a kwarg to make this explicit.
JDH

Hi all!
I'm using version 0.91.2, but by looking at the svn repository is seems 
this issue still exists.
There seems to be a bug in the getpoints() method in the YAArrow class. 
When I execute the commands
from pylab import *
annotate('Oops...', (.2, .2), (.2, .6), arrowprops=dict(width=3))
show()
(note that the x2-x1==0) I get the error:
Traceback (most recent call last):
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 331, in expose_event
 self._render_figure(self._pixmap, w, h)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 358, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
624, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1345, in draw
 a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1246, in draw
 self.update_positions(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1242, in update_positions
 **d)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
678, in __init__
 verts = self.get_verts()
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
690, in get_verts
 xb1, yb1, xb2, yb2 = self.getpoints(x1, y1, x2, y2, k1)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
714, in getpoints
 m = (y2-y1)/(x2-x1)
ZeroDivisionError: float division
Traceback (most recent call last):
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 331, in expose_event
 self._render_figure(self._pixmap, w, h)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 358, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
624, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1345, in draw
 a.draw(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1246, in draw
 self.update_positions(renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1242, in update_positions
 **d)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
678, in __init__
 verts = self.get_verts()
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
690, in get_verts
 xb1, yb1, xb2, yb2 = self.getpoints(x1, y1, x2, y2, k1)
 File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 
714, in getpoints
 m = (y2-y1)/(x2-x1)
ZeroDivisionError: float division
It seems that the function getpoints() doesn't take care of the 
situations when the slope of the line (x1,y1,x2,y2) is zero or infinity. 
This could be solved with the simple check in the function:
if y2-y1 == 0:
	return x2, y2+k, x2, y2-k
elif x2-x1 == 0:
	return x2+k, y2, x2-k, y2
This fixes it for me.
By the way, I just found out about matplotlib, and I find it extremely 
useful! Thanks to all devs for creating this :).
Cheers,
Tuukka Verho

On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <Dav...@ir...> wrote:
> So just to make sure that I understand this, "MyInteractiveBackend"
> would be any backend canvas class for whom we want to implement the
> standard generic mixin. For example, the class FigureCanvasGTK would
> inherit FigureCanvasEventLoopMixin until we get around to writing
> something specific for GTK. On the other hand, FigureCanvasWx wouldn't
> inherit the mixin, but would use the WX specific code you sent
> yesterday. And FigureCanvasPs wouldn't get anything at all. Am I
> getting this?
>
> If so, then I will go ahead and make the appropriate modifications.
> Looking at the list of backends, I think it suffices to inherit the
> mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk,
> qt4, qt, tkagg (wx covered with its own code). All other interactive
> backends should inherit from these. The ones with the question marks I
> am not really sure about, but will assume true unless told otherwise.
I'm not a huge fan of mixins. We use them occassionally, eg for
FigureCanvasGtkAgg and their are some good uses for them, but they can
quickly lead to overly complex code so should be avoided where
possible. I find the "deeper hierarchy" approach more appealing here,
but am not sure if it is viable. For example
 class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg)
inherits from an interactive and a non-interactive backend, which is a
good example of how quickly multiple mixin inheritance can get tricky.
 I think perhaps it is best to create no new classes, put the base
methods in the FigureCanvasBase, make the default behavior
non-interactive, and then overrride them for the GUI backends. Any
problems with this?
Finally, the term "interactive" is a bit confusing and overloaded
here, since "is_interactive" in mpl means someone is working from the
interactive shell and we want to update the figure on every command
(if draw_if_interactive). For clarity, I think we should refer to
this as a "user interface" backend or something like that,. I know in
parts of the backend code we have the designation of interactive
backends, but these variables should probably be renamed to avoid
further confusion, since the other use of interactive is already
enshrined in the frontend api and rc file.
JDH

On Fri, Jul 18, 2008 at 2:04 AM, Gael Varoquaux
<gae...@no...> wrote:
> On Fri, Jul 18, 2008 at 07:36:03AM +0200, Gael Varoquaux wrote:
>> On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote:
>> > I think we could do a 0.98.3 release.
>
>> I am right now implementing a wx frontend to ipython, and I can see in
>> the near future a score of people complaining that "from pylab import *;
>> show()" crashes it because it calls the wrong backend. Do people mind if
>> I prepare a patch that does some magic as pylab is loaded to:
>> a) Look if 'wx' is in sys.module
>> b) Check if the wx mainloop is running,
>
>> and if so changes the backend automatically to wx and wxAgg.
ipython Shell.py already hacks wx, gtk, and tk to make sure mpl's
mainloop is not going to cause any problems (eg
IPython.Shell.hijack_wx). Is there something about the new ipython wx
frontend design that requires a different solution for mpl?
I'm happy to hold the release until we get this sorted out, but before
I review the patch maybe you can let me know what if anything is
different about the new ipython design that requires changes in mpl
because I haven't followed the ipython redesign closely enough.
JDH

Hi,
On Thu, 2008年07月17日 at 16:55 -0400, Paul Kienzle wrote:
> FigureCanvasBase:
> def start_event_loop(self, ...): 
> raise NotImplemented
> FigureCanvasEventLoopMixin:
> def start_event_loop(self, ...):
> generic interactive using time.sleep
> MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
> ... no start_event_loop since using the generic mixin ...
> 
So just to make sure that I understand this, "MyInteractiveBackend"
would be any backend canvas class for whom we want to implement the
standard generic mixin. For example, the class FigureCanvasGTK would
inherit FigureCanvasEventLoopMixin until we get around to writing
something specific for GTK. On the other hand, FigureCanvasWx wouldn't
inherit the mixin, but would use the WX specific code you sent
yesterday. And FigureCanvasPs wouldn't get anything at all. Am I
getting this?
If so, then I will go ahead and make the appropriate modifications.
Looking at the list of backends, I think it suffices to inherit the
mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk,
qt4, qt, tkagg (wx covered with its own code). All other interactive
backends should inherit from these. The ones with the question marks I
am not really sure about, but will assume true unless told otherwise.
I agree with Gael that warning is probably sufficient. This will allow
code running in the background to pass over interactive commands such as
ginput. This may be better than an immediate error, but could cause
problems later in the script when data is expected, but one gets [].
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,
I just committed some changes to deal with these comments. Responses
below.
Cheers, David
On Thu, 2008年07月17日 at 15:16 -0500, John Hunter wrote:
> def __init__(self, fig, eventslist=()):
> self.fig = fig
> assert isinstance(eventslist, tuple), "Requires a tuple of
> event name strings"
> self.eventslist = eventslist
> 
> I would probably write a cbook method is_sequence_of_strings and just
> call that since it will be more readable and reusable...
> 
Method added to cbook.
> I notice there are some residual print statements in the code -- these
> should be replaced by the verbose handler in matplotlib/__init__.py,
> eg in
> 
> if timeout > 0 and counter > timeout/0.01:
> print "Timeout reached";
> break;
> 
> and
> if self.verbose:
> print "input %i: %f,%f" % (len(self.clicks),
> event.xdata, event.ydata)
> 
> and others in contour.py
> 
> You can replace these with
> 
> import matplotlib
> matplotlib.verbose.report('something')
> 
> and
> 
> matplotlib.verbose.report('some nitty gritty details', 'debug')
> 
> There should be no prints in mpl.
> 
Fixed.
> In contour.py, we have
> 
> xmax = np.amax(np.array(linecontour)[:,0])
> xmin = np.amin(np.array(linecontour)[:,0])
> ymax = np.amax(np.array(linecontour)[:,1])
> ymin = np.amin(np.array(linecontour)[:,1])
I noticed these previously, but didn't touch them as this is in the part
of the code that is somewhat mysterious to me. linecontour should
always be an array (at least the linecontours in a Path), so I don't see
much point in forcing it to array. I have removed these and several
other np.array or np.asarray calls that seemed extraneous to me. If
desired, I can include a single np.array call, but I don't think it is
required.
Thanks,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Ryan May wrote:
> John Hunter wrote:
>> On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:
>>
>>> I welcome any comments/criticism to help improve this.
>> Hey Ryan,
>>
>> I have looked at this code briefly and have a few minor comments. I
>> think Eric, who did the bulk of the current quiver implementation, and
>> as an oceanographer is in a field much closer to yours than mine, will
>> provide more useful feedback and should ultimately handle the patch
>> submission.
I would be happy to do so.
>>
>> My first comment is that the code looks very good -- it is well
>> thought out and commented, and t is definitely suitable for inclusion
>> in the main line. Certainly the Barbs class can live in the
>> collections module. You note in the driver code that you are worried
>> about pollution of the axes namespace by including a domain specific
>> method, and this is a reasonable worry, but the axes namespace is
>> currently so polluted with plotting methods that it is a small worry.
>> I think it would be fine for you to rework your code into a patch
>> which provides the Barbs collection in matplotlib.collections, an Axes
>> method, and a pyplot interface function (with a pylab module level
>> docstring entry). The overloading of the Axes namespace is not ideal,
>> but it's what we've got.
> 
> Thanks. My question then is how do I add a pyplot interface, since it 
> appears from the comments that many of those are just generated boilerplate?
If all that is needed is a standard wrapper, then you add an entry to 
the appropriate list in boilerplate.py (which is in the root mpl 
directory, alongside CHANGELOG etc.), and run it to generate all the 
boilerplate, and then substitute that output for the corresponding chunk 
at the end of pyplot.py. (Or do some variation on this procedure that 
gives the same end result.)
> 
>> My second comment has to do with your comment at the end of the example:
>>
>> #Showing colormapping with uniform grid. Unfortunately, only the flags
>> #on barbs get colormapped this way.
>>
>> On a cursory read of the code, it looks like you have implemented
>> everything as a single poly collection, and the reason the flags only
>> get colored is that the varicolored is black. It seems like there are
>> two solutions: write your class as a combination of poly collection
>> (for the flags) and line collection (for the barbs) and colormap both
>> (there are some line collection colormapping examples in the examples
>> subdir courtesy of Eric). The 2nd alternative, which I haven't
>> explored, is to set the edgecolor equal to the facecolor and support
>> colormapping of the edgecolors.
Isn't this already done? Here is a Collections method:
 def set_edgecolor(self, c):
 """
 Set the edgecolor(s) of the collection. *c* can be a
 matplotlib color arg (all patches have same color), or a
 sequence or rgba tuples; if it is a sequence the patches will
 cycle through the sequence.
 If *c* is 'face', the edge color will always be the same as
 the face color.
 ACCEPTS: matplotlib color arg or sequence of rgba tuples
 """
 if c == 'face':
 self._edgecolors = 'face'
 else:
 if c is None: c = mpl.rcParams['patch.edgecolor']
 self._edgecolors = _colors.colorConverter.to_rgba_array(c, 
self._alpha)
And in the draw method:
 if self._edgecolors == 'face':
 edgecolors = self._facecolors
 else:
 edgecolors = self._edgecolors
 renderer.draw_path_collection(
 transform.frozen(), self.clipbox, clippath, clippath_trans,
 paths, self.get_transforms(),
 offsets, transOffset,
 self._facecolors, edgecolors, self._linewidths,
 self._linestyles, self._antialiaseds)
Am I missing something? (Probably--I have not looked very closely at 
barb yet.)
Eric
> 
> Yeah, the comment went more to explain expected results. There was no 
> mystery to me why the edgecolors didn't get colormapped, it was pretty 
> clear from the collections code. I had started down the road of 
> combining lines and polygons in a PatchCollection, but that created a 
> bunch of separate objects for each wind barb that had to each be 
> transformed and have an offset applied. I took the lazy way out and 
> created (admittedly) degenerate polygons. :) I hadn't actually thought 
> (call it a brain fart) about actually going ahead and adding 
> colormapping for the edgecolors. Should I follow Mike's suggestion and 
> possibly take a go at adding it to the general Collections class? 
> (Granted, if someone else took a stab at it, it might land in SVN 
> sooner, I'm sure I still have a learning curve to go here).
> 
>> Overall this is very promising, and I wish you the best trying to make
>> mpl serviceble to the meteorology community. Jeff Whitaker has done a
>> phenomenal job with basemap providing extensions for those needing
>> cartographic projections as a toolkit. Depending on how far you want
>> to go with meteorological support, we can include the changes in the
>> mainline or fold them into a toolkit if they become hyper-specialized.
> 
> I still have a few more things to add (on top of what Whitaker already 
> fixed for me):
> 
> * Need to plot something (empty circle) for vector magnitude < 5. (I 
> did a plot the other day and was befuddled for a bit by seeing only 6 barbs)
> * Need to fix support for masked arrays. The way the iteration goes 
> right now, masked values end up being iterated over, which is bad.
> * Probably should add a set_uv(c) method, like quiver
> 
> We'll see about the possibility of a toolkit. If I can keep up the 
> momentum, I might end up with significant functionality. I'd also have 
> to see how much of it really ends up being more than just simple example 
> scripts. And I agree, huge props to Whitaker for Basemap. Hopefully I 
> can get more people around me to use it instead of the abominations used 
> now. :)
> 
> (I'd have things sooner if it weren't for the stupid Google CodeJam :) )
> 
> Ryan
> 

Hi,
Just a remark:
 GTKAgg on win32 is a combination I also use every day.
And I think many people also use it.
GTK is the almost only (nice) toolkit providing straightaway the same 
look and feel independantly of the platform used. This is very important 
if you would like to deploy the same software on an heterogeneous 
environment and you don't want users to rediscover the same software on 
different platforms.
I personally prefer to use the "same" Gimp, whatever I'm in front of a 
Linux, Windows or Mac platform. And believe me or not, It happens almost 
everyday in my research environment where I have a Mac on my desk, 
windows platform controlling experiments, Unix stations running 
simulation softwares and a Linux when I come back home...
Sorry for hijacking this thread, I was I bit chocked by John statement 
and wanted to react.
All the best,
David
John Hunter a écrit :
> On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Has anyone ever noticed weirdness with translucent polygons on win32
>> (using GTKAgg)? I had the occasion to actually do something on windows
>> and noticed that, having drawn some polygons with alpha < 1, if I
>> resized the window or panned, the alpha channel seemed to disappear and
>> leave solid-colored polygons.
> 
> gtkagg on win32 is a very unusual combination -- one I used a lot in
> the day myself but it seems noone else did. It is really hard to
> understand how something like this can happen from the way the code is
> written, but yes, if you can get any insight into it, we'd certainly
> like to understand and fix it. I have at least one fairly significant
> piece of code that requires gtkagg on windows....
> 
> For starters, just posting the output of a script run with
> --verbose-helpful so we can get some version info for the archives
> will be useful.
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Jul 18, 2008 at 07:36:03AM +0200, Gael Varoquaux wrote:
> On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote:
> > I think we could do a 0.98.3 release. 
> I am right now implementing a wx frontend to ipython, and I can see in
> the near future a score of people complaining that "from pylab import *;
> show()" crashes it because it calls the wrong backend. Do people mind if
> I prepare a patch that does some magic as pylab is loaded to:
> a) Look if 'wx' is in sys.module
> b) Check if the wx mainloop is running,
> and if so changes the backend automatically to wx and wxAgg.
OK, no replies tonight, so I went ahead and coded a patch, in the
interest of getting this in before the next release. It is attached.
Comments are welcome.
Gaël

On Thu, Jul 17, 2008 at 04:55:42PM -0400, Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 09:44:48PM +0200, David M. Kaplan wrote:
> > Another option would be to create a start_event_loop function like Paul
> > suggested and overload that function in those backends that aren't
> > interactive so that it returns an error, but this requires writing one
> > such function for each non-interactive backend.
> Either create a deeper hierarchy:
> FigureCanvasBase:
> def start_event_loop(self, ...): 
> raise NotImplemented
> FigureCanvasInteractive:
> def start_event_loop(self, ...):
> generic interactive using time.sleep
> MyInteractiveBackend(FigureCanvasInteractive):
> def start_event_loop(self, ...):
> specialized interactive code using GUI 
> or a mix-in class:
> FigureCanvasBase:
> def start_event_loop(self, ...): 
> raise NotImplemented
> FigureCanvasEventLoopMixin:
> def start_event_loop(self, ...):
> generic interactive using time.sleep
> MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
> ... no start_event_loop since using the generic mixin ...
> I prefer the latter, particularly since it won't be needed once the
> existing interactive backends are implemented.
+1 one that.
Also, I don't think a exception is a good idea. Simply a warnings.warn
should be enough.
Gaël

On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote:
> I think we could do a 0.98.3 release. 
I am right now implementing a wx frontend to ipython, and I can see in
the near future a score of people complaining that "from pylab import *;
show()" crashes it because it calls the wrong backend. Do people mind if
I prepare a patch that does some magic as pylab is loaded to:
a) Look if 'wx' is in sys.module
b) Check if the wx mainloop is running,
and if so changes the backend automatically to wx and wxAgg.
I could not sleep and do this tonight to get it ready for the release,
but I would like people's feedback... (Famous last words)
Gaël