matplotlib-devel Mailing List for matplotlib (Page 11)

Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location. However, 
if nothing is drawn for a location X,Y where U,V are masked, this would 
seemingly lead to a problem where the locations and the things to be 
drawn get out of phase. Am I missing something here? Eric, did I miss 
some magic somewhere in quiver that handles this?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

 if (hasattr(x, 'get_compressed_copy')):
 compressed_x = x.get_compressed_copy(mask)
John,
You added the snippet above to axes.delete_masked_points as part of one 
of your massive "units" patches. It needs at least a comment in the 
code--which I would be happy to add, based on your reply--because I 
don't see any such attribute in mpl or numpy. My guess is that it is 
specific to the JPL array-like objects which motivated the units support.
Thanks.
Eric

Hi,
On Fri, 2008年07月18日 at 15:47 -0400, Paul Kienzle wrote:
> The cases I'm thinking about (e.g., select fit range) have a specific 
> number of points. Other cases (e.g., select shape outline) have an
> indefinite number of points. I can't think of case off hand where
> I would want e.g., six or fewer points.
A good use case of this is a nested zoom functionality - I often use the
following code to implement a simple nested zoom to look at areas of
figures while flipping through a large series of figures (i.e., in cases
where stopping and restarting the code is a bit awkward):
while True:
 x = ginput(2)
 if len(x)<2: break
 x.sort(0)
 axis(x.T.ravel())
Another use is drawing a contour as you click points.
I am still thinking that changing the default timeout to -1 is a good
idea - this agrees with matlab and forces the naive user to choose fewer
points rather than inadvertantly letting it happen.
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
**********************************

On Sat, Jul 19, 2008 at 07:31:19AM +0200, Gael Varoquaux wrote:
> - show starts a mainloop and is blocking even if there are not windows
> open. This basically leads to a deadlock where the user cannot
> interrupt the mainloop. This can probably be easily fixed, and I'll
> look into it.
It turns out it was only in the GTK backend, and quite trivial to
correct. Attached is a new patch, including this correction.
Gaël

I forgot to mention: fltk and cocoa did not get any love at all in this
patch. The reason being that I do not know of any program running the
first one, and for me to test and develop things for the second one,
somebody will have to offer me an apple computer :).
Cheers,
Gaël

I have implemented a prototype of interactive backend detection. As I
proposed earlier, I added an extra rc parameter 'backend_fallback' that
allows pyplot to inspect sys.modules on load and try to redirect
interactive backends to the appropriate ones.
I am attaching a patch, not for inclusion, as I still want to check
different details on interactivity, and the behavior of the show command,
but for comments and triage. I have tested it in various apps, and I
think it is interesting to review the different mainstream apps
presenting a interactive shell in which pylab can be used interactively.
* wx apps. In mayavi2, my near-born ipython frontend the attached patch 
 works seamlessly, with or without the interactive switch. In SPE 
 (wx-based IDE) it does not work, and I suspect this is because of ugly 
 things SPE does to the wx image-loading, for theming reasons, as I see
 totally unrelated errors. 
* Qt: In Eric4 the qt detection does not work as it seems that Eric 
 spawns a new python process. As a result, as long as you keep the 
 interactive switch off, pylab works great, but you really have to use a 
 blocking show. Does anybody now a Qt program that has an interactive
 Python prompt?
* In IDLE I can't figure out what is happening. I must confess that I do not 
 know much about Tkinter, and I am not too sure how matplotlib is
 supposed to collaborate with an existing Tk mainloop.
* The only GTK program I could think of with an interactive python prompt
 was accerciser, an pylab now works out of the box there, in interactive
 mode or not.
Of course in ipython -q|q4|w|g-thread, my addition work seamlessly, but
that was too easy :).
Some remarks that came out of this extensive testing:
 - show starts a mainloop and is blocking even if there are not windows
 open. This basically leads to a deadlock where the user cannot
 interrupt the mainloop. This can probably be easily fixed, and I'll
 look into it.
 - we cannot guess whether the user want to be in interactive mode or
 not: there is a potential large cost of being in interactive mode due to 
 continuous refreshing of the UI. Ipython gets it right by turning the
 interactive mode off when running a script, but when need the host
 environment to make this decision and we cannot make it in matplotlib.
 However, I believe it is important to expose more this
 functionality, as the user will now probably have to make this
 decision. This is why I have add the import of "interactive" in
 pyplot.
 - this brings up the fact that the user experience can be increased a
 lot if the host environment collaborates with matplotlib. This is why
 we discussed with John the idea of adding a "vendor registry", a
 light-weight module that an environment could import at little cost
 to tell matplotlib what backend to use, whether to put the
 interactive switch, and hopefully more, like maybe a factory to
 create new figure, as this would allow embedding these figures in an IDE.
 We do this with mayavi2, where the figures created by mlab are
 standalone windows when the fullblown environment is not running, but
 integrated windows when it is running.
I am sure there is more that we can learn. Please come up with ideas so
that we can see better what is the way forward for integrating matplotlib
to graphical shells and environments.
Cheers,
Gaël

On Sat, Jul 19, 2008 at 01:25:51AM +0200, Gael Varoquaux wrote:
> Am I wrong, or does matploib not build with current numpy svn?
OK, Fernando told me that matplotlib builds fine with latest numpy on his
box so Ienquired a bit more. The problem is that the build of matplotlib
tries to include a header file that is generated automatically during the
build of numpy (__multiarray_api.h). If you install numpy using "python
setup.py install", this header file is inlcuded in the install. However I
used "python setupegg.py develop" to install numpy. As a result the
header file does not get put in the include directory. I guess this is
thus a bug in the setupegg.py of numpy, but my knowledge of setuptools is
way to low to be able to fix that.
Cheers,
Gaël

Hi,
Am I wrong, or does matploib not build with current numpy svn?
Here is the error message I am getting:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC
-I/home/varoquau/dev/numpy/trunk/numpy/core/include
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
-I/usr/include/python2.5 -c src/ft2font.cpp -o
build/temp.linux-i686-2.5/src/ft2font.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
In file included from
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/arrayobject.h:14,
 from src/ft2font.cpp:6:
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:17:25:
error: numpyconfig.h: No such file or directory
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:1829:30:
error: __multiarray_api.h: No such file or directory
src/ft2font.cpp: In member function ‘Py::Object
FT2Image::py_as_array(const Py::Tuple&)’:
src/ft2font.cpp:273: error: ‘PyArray_Type’ was not declared in this scope
src/ft2font.cpp:273: error: ‘PyArray_New’ was not declared in this scope
src/ft2font.cpp: In function ‘void initft2font()’:
src/ft2font.cpp:1877: error: ‘import_array’ was not declared in this
scope
error: command 'gcc' failed with exit status 1
If you look at the numpy/core/include/numpy/ndarrayobject.h file, it says
clearly at the top of the file "do not include this file directly".
Gaël

On Fri, Jul 18, 2008 at 4:17 PM, Andrew Straw <str...@as...> wrote:
> Yes, good idea. (In fact I wonder why numpy doesn't have minmax.)
I've often wondered this myself...
Cheers,
f

Eric Firing wrote:
> John Hunter wrote:
>> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <str...@as...>
>> wrote:
>>
>>> If you're happy with that extra cost, I'll modify
>>> axes.delete_masked_points() so that hexbin and scatter are automatically
>>> filtered in this way. Given the speed complaints we sometimes get, I was
>>> hesitant to add another pass through the data.
> 
> masks.extend([~np.isfinite(x) for x in args])
> 
> may be the quickest and most general way to do it. I believe
> ~np.isfinite is both more general and significantly faster than np.isnan.
Clever, but it won't work as-is. np.isfinite('b') returns a
NotImplementedType, and a default argument to scatter is c='b', which
gets passed to this function. Anyhow, I implemented your idea with a
check for NotImplementedType and some unit tests in r5791.
> A kwarg could be used to enable or disable this checking.
Yes, but since we're grabbing *args, that would mean parsing **kwargs --
so I just implemented it without the option of disabling it. I'm happy
to add this if desired.
>> Happy is the wrong word -- we certainly should make these things as
>> efficient as reasonable so if your optimization worked it would be
>> preferable numpy passes are rarely the bottleneck but they are good
>> to be aware of. We could provide some helper function in nxutils to
>> do more stuff in a single pass for common use cases (eg a minmax
>> function to get both the min and the max...)
Yes, good idea. (In fact I wonder why numpy doesn't have minmax.) And
apologies for suggesting that you might be "happy" with a (minor)
slowdown -- not the best choice of words.
-Andrew

John Hunter wrote:
> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <str...@as...> wrote:
> 
>> If you're happy with that extra cost, I'll modify
>> axes.delete_masked_points() so that hexbin and scatter are automatically
>> filtered in this way. Given the speed complaints we sometimes get, I was
>> hesitant to add another pass through the data.
masks.extend([~np.isfinite(x) for x in args])
may be the quickest and most general way to do it. I believe 
~np.isfinite is both more general and significantly faster than np.isnan.
A kwarg could be used to enable or disable this checking.
Eric
> 
> Happy is the wrong word -- we certainly should make these things as
> efficient as reasonable so if your optimization worked it would be
> preferable numpy passes are rarely the bottleneck but they are good
> to be aware of. We could provide some helper function in nxutils to
> do more stuff in a single pass for common use cases (eg a minmax
> function to get both the min and the max...)
> 
> -------------------------------------------------------------------------
> 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 4:42 PM, Andrew Straw <str...@as...> wrote:
> If you're happy with that extra cost, I'll modify
> axes.delete_masked_points() so that hexbin and scatter are automatically
> filtered in this way. Given the speed complaints we sometimes get, I was
> hesitant to add another pass through the data.
Happy is the wrong word -- we certainly should make these things as
efficient as reasonable so if your optimization worked it would be
preferable numpy passes are rarely the bottleneck but they are good
to be aware of. We could provide some helper function in nxutils to
do more stuff in a single pass for common use cases (eg a minmax
function to get both the min and the max...)

John Hunter wrote:
> On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <str...@as...> wrote:
> 
>> I just spent a little time getting hexbin to discard nans without
>> failing in mysterious ways.
>>
>> I'm sending 2 patches: one will detect nans and raise a suitable
>> exception. The other will automatically drop the nans and continue with
>> hexbin. The 2nd seems a little nicer in functionality, but the code is a
>> little more convoluted and hence more brittle, and so I'm torn as to
>> which I'd prefer. (The problem with just detecting nans from the
>> beginning is that it would cause an extra pass through the data in all
>> cases.)
>> 
>
> I think the nans should be dropped with no raise or warning, which is
> consistent with our handling elsewhere. I don't think your approach,
> which if I am reading this correctly assumes that is x or y has nans
> then the min or max will be nan, is correct. Eg,
>
> In [51]: x = np.random.rand(10)
>
> In [52]: x[4] = np.nan
>
> In [53]: x.min()
> Out[53]: 0.37072898459621617
>
> In [54]: x.max()
> Out[54]: 0.79367039009185769
>
>
> I think min and max in the presence of nans is undefined.
True -- that slipped past me, since in my use case the nans were always
coming out for both min and max...
> But you can
> just pay for the extra pass
>
> mask = np.isnan(x) & np.isnan(y)
> if mask.any():
> # mask where
If you're happy with that extra cost, I'll modify
axes.delete_masked_points() so that hexbin and scatter are automatically
filtered in this way. Given the speed complaints we sometimes get, I was
hesitant to add another pass through the data.
-Andrew

On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <str...@as...> wrote:
> I just spent a little time getting hexbin to discard nans without
> failing in mysterious ways.
>
> I'm sending 2 patches: one will detect nans and raise a suitable
> exception. The other will automatically drop the nans and continue with
> hexbin. The 2nd seems a little nicer in functionality, but the code is a
> little more convoluted and hence more brittle, and so I'm torn as to
> which I'd prefer. (The problem with just detecting nans from the
> beginning is that it would cause an extra pass through the data in all
> cases.)
I think the nans should be dropped with no raise or warning, which is
consistent with our handling elsewhere. I don't think your approach,
which if I am reading this correctly assumes that is x or y has nans
then the min or max will be nan, is correct. Eg,
 In [51]: x = np.random.rand(10)
 In [52]: x[4] = np.nan
 In [53]: x.min()
 Out[53]: 0.37072898459621617
 In [54]: x.max()
 Out[54]: 0.79367039009185769
I think min and max in the presence of nans is undefined. But you can
just pay for the extra pass
mask = np.isnan(x) & np.isnan(y)
if mask.any():
 # mask where
JDH

On Fri, Jul 18, 2008 at 07:57:25PM +0200, Gael Varoquaux wrote:
> 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.
I talk to Fernando about this, and he came up with a suggestion I like
quite a lot. The idea would be to give an "backend_fallback" boolean in
the rc parameters. When loading an interactive backend, if this boolean
is set to true (by default), the backend-loading code would check that
the proposed interactive backend is complatible with the current running
mainloop, and if not walk the different backends to find a suitable one,
without shooting a warning at the user, because the user should not have
to know about this.
I think this is a good way of satisfying both the requirement for
seemless operation in different event loops and the requirement for
advanced users that can control completely how things happen using the rc
parameter switch. Moreover, if there is not risk of conflict, the
rc-specified choice would be kept.
What do you think? Where should I insert this code?
Cheers,
Gaël

On Fri, Jul 18, 2008 at 3:00 PM, Andrew Straw <str...@as...> wrote:
> It appears the current svn trunk has a problem in that gtk.main() in
> backend_gtk.py line 71 never returns, even after all windows have been
> closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the
> window. This does not happen with WXAgg or TkAgg.
Arg, while trying to debug another problem I commented out a relevant
line and forgot to uncomment. Should be fixed in 5790. Thanks for
the report.
JDH

John Hunter wrote:
> 
> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
It's at the top of my list ATM. I've let this afternoon get away from 
me, but I have literally *nothing* to do tomorrow and Sunday, so expect 
a patch this weekend. (Let's hope I haven't jinxed myself here.)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

It appears the current svn trunk has a problem in that gtk.main() in
backend_gtk.py line 71 never returns, even after all windows have been
closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the
window. This does not happen with WXAgg or TkAgg.
-Andrew

I just spent a little time getting hexbin to discard nans without
failing in mysterious ways.
I'm sending 2 patches: one will detect nans and raise a suitable
exception. The other will automatically drop the nans and continue with
hexbin. The 2nd seems a little nicer in functionality, but the code is a
little more convoluted and hence more brittle, and so I'm torn as to
which I'd prefer. (The problem with just detecting nans from the
beginning is that it would cause an extra pass through the data in all
cases.)
Anyhow, I've attached them both here for discussion. I'm happy to check
one of these in myself or feel free to do it.
-Andrew

On Fri, Jul 18, 2008 at 09:17:02PM +0200, David M. Kaplan wrote:
> For ginput, there are a number of ways that an impartial list could be
> returned and this is often a desired outcome (for example, I often
> decide after the fact that I want fewer points than I initially
> thought).
Can't you use ginput(0) for these cases? 
It doesn't work on Mac with no middle mouse button to terminate the 
sequence, but that is a separate issue.
> Perhaps as a compromise we could set the default timeout to
> -1 so the user needs to actually choose a timeout (presumably indicating
> he/she accepts the consequences). But allowing the user to manually
> decide to select fewer points using the second mouse button has proved
> quite useful to me and the user would still need to test in this case.
> We could warn if not enough points are returned, but an error seems too
> much to me. 
The cases I'm thinking about (e.g., select fit range) have a specific 
number of points. Other cases (e.g., select shape outline) have an
indefinite number of points. I can't think of case off hand where
I would want e.g., six or fewer points.
That said, I can always wrap the function in my own interface for my
scripts.
	- Paul

John Hunter wrote:
> 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.
Well what was real enough yesterday, today I can't reproduce. Maybe it 
was just some windows weirdness. I'll let you know if I see it again 
(but I'm not sure that I'll have any reason to be doing much on windows 
in the near future.) Sorry for the noise.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
On Fri, 2008年07月18日 at 09:24 -0500, John Hunter wrote:
> On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <Dav...@ir...> wrote:
> 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)
> 
Actually the case of GTKAgg is an interesting one. I have
FigureCanvasGTK inherit the mixin, but this doesn't cascade to GTKAgg
because it gets overloaded with the non-user-interface versions from
FigureCanvasAgg leading calls to ginput to produce an error. Adding the
mixin to the end of GTKAgg's inheritance list didn't work because it
seems that python decides that Agg has already overwritten the same
mixin included by GTK and ignores the mixin inheritance at the end of
the list (this surprised me, but it appears to work that way). One
could always force it to use the right ones by adding functions that
point to the mixin versions, but this seems less elegant than
inheritance.
In this and similar cases, is the order of inheritance important?
Changing it to (FigureCanvasAgg, FigureCanvasGTK) should fix the
problem. 
> 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?
> 
Well, yeah. I think this would mean a lot of the same code in many
backends. I also like the idea of a deeper hierarchy with a
FigureCanvasUserInterface class that inherits FigureCanvasBase but adds
functional start/stop_loop_events because it would allow for a simple
cbook test for a working user interface:
isinstance(mycanvas,FigureCanvasUserInterface)
A deeper hierarchy won't help the inheritance problem for GTKAgg though.
> 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.
> 
I agree.
> JDH
-- 
**********************************
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,
On Fri, 2008年07月18日 at 11:52 -0400, Paul Kienzle wrote:
> If exceptions aren't used, then non-interactive backends should
> return []
> 
I think I have changed my mind on this one - an error seems more
appropriate. The real-world use cases for this are (1) someone doesn't
realize they are in a non-user-interface backend and runs ginput and (2)
someone is running in the background a script that contains interactive
elements. In both cases, using these functions is almost certainly an
error on the users side and it is impossible to decide what the user
would like to have returned in this case. If the user really wants
potentially non-interactive run of the code, he could use try, except to
deal with that.
> 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
> 
For ginput, there are a number of ways that an impartial list could be
returned and this is often a desired outcome (for example, I often
decide after the fact that I want fewer points than I initially
thought). Perhaps as a compromise we could set the default timeout to
-1 so the user needs to actually choose a timeout (presumably indicating
he/she accepts the consequences). But allowing the user to manually
decide to select fewer points using the second mouse button has proved
quite useful to me and the user would still need to test in this case.
We could warn if not enough points are returned, but an error seems too
much to me. 
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,
My bad - I forgot strings are iterable. This should now be fixed.
Cheers,
David
On Fri, 2008年07月18日 at 09:41 -0500, John Hunter wrote:
> 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
-- 
**********************************
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
**********************************

John Hunter wrote:
> 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
> 
John: Well, I hit one snag. One file in natgrid has this comment in it.
/*
 * The code in this file is based on code written and
 * copyrighted (C) by Dave Watson. Dr. Watson retains the
 * copyright to his original code. Augmentations and changes
 * to Dr. Watson's code are copyrighted (C) by UCAR, 1997.
 */
The NCAR folks have not been able to contact the fellow, and suspect he 
may have passed on. I can't verify this though. Do you see this as a 
problem?
-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