Re: [matplotlib-devel] patch for adding manual label location selection to clabel
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 ** - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] get_compressed_copy is found where?
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Masked arrays in Quiver/Windbarbs
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Progress on interactive backend detection
On Sat, Jul 19, 2008 at 1:05 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > It turns out it was only in the GTK backend, and quite trivial to > correct. Attached is a new patch, including this correction. Hey Gael, this is starting to look reasonable. I know implementing these checks, such as detecting whether the mainloop is active, can be a hassle, so thanks for taking the time to write against so many environments. We may want to make take the logic you've provided and encapsulate them in the backend methods to make them more easily recognizable, fixable and reusable. Eg, each unser interface backend would provide a "mainloop_running" method. You could then access this in pyplot to support your fallback logic, and also we could use it in "show" to make sure we don't try and start mainloops that are already running. One thing notice in your patch is that when it comes time to check for tk, you import tkinter and then do nothing with it. I assume this is a placeholder until you figure out what you want to do? For a little background, Fernando, Gael and I talked about this problem a bit over the phone yesterday. The use case they are trying to address is that people may be wanting to use more than one application, at different times or at the same time, that have embedded python shells. With all the work going on making ipython frontends for wx, qt and gtk, it is not unreasonable to assume that there ill soon be multiple IDEs or other environment in which one might want to import and use pylab. Since we only support one default backend, and it is dificult and onerous for the user to constantly modify their rc depending on what application they may be launching, Fernando and Gael proposed supporting a backend fallback option so the user could express the intention: use my default backend unless I happen to be in an incompatible user interface environment and then just choose the most sensible thing. Users who do not want this magic can simply turn the fallback option off. This behavior will only be triggered if 1) the fallback option is on (it will be by default) 2) the user is running mpl in an environment in which a user interface already has a running mainloop 3) the default backend is known to be incompatible. Eg, if the default backend is PS, nothing will happen. I think the proposed changes are reasonable. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Empty wind barb suggestion
Hi, In trying to add a symbol for an empty wind barb, I ran into problem. Traditionally, a smaller, non-filled circle is used for low wind speeds when doing a barb plot. I can draw the circle easily as a polygon, using CirclePolygon from patches, but unfortunately, the fill color for this polygon ends up being the same as the color of the flags on the barbs. Therefore, as currently implemented, the only way to have unfilled circles is to have unfilled flags. The only technical solution I can think of here is to have separate collections for the circles and the polygons. Unfortunately, I have no idea how to begin to do that within a class that inherits from collections. Another option would be to somehow manually set the fill colors on the circles after the collection is initialized. Anyone have suggestions on how to make this work, or maybe a better technical solution. Jeff, how aesthetically displeasing do you think it would be to have small (possibly colored) circles to represent the low winds instead of the traditional (somewhat larger) hollow circle? It would make it impossible to do sky cover in a traditional surface map, but maybe Z-ordering could be used to hack around it. Thoughts, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Progress on interactive backend detection
John Hunter wrote: > Fernando and Gael proposed supporting a backend fallback option so the > user could express the intention: use my default backend unless I > happen to be in an incompatible user interface environment and then > just choose the most sensible thing. Users who do not want this magic > can simply turn the fallback option off. This behavior will only be > triggered if > > 1) the fallback option is on (it will be by default) > 2) the user is running mpl in an environment in which a user > interface already has a running mainloop > 3) the default backend is known to be incompatible. Eg, if the > default backend is PS, nothing will happen. > > I think the proposed changes are reasonable. > +1 Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Collections set/get_offsets method
Hi, As promised, here's a short patch to add get_offsets() and set_offsets() to the Collections() base class. I tried to make it do the right thing with regard to _offsets vs. _uniform_offsets, depending on whether _uniform_offsets is None. I also had tried to make __init__ use set_offsets, but that proved to be too much of a hassle for too little code reuse. Comments? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma --- collections.py (revision 5792) +++ collections.py (working copy) @@ -222,6 +222,32 @@ def set_pickradius(self,pickradius): self.pickradius = 5 def get_pickradius(self): return self.pickradius +def set_offsets(self, offsets): +""" +Set the offsets for the collection. *offsets* can be a scalar +or a sequence. + +ACCEPTS: float or sequence of floats +""" +offsets = np.asarray(offsets, np.float_) +if len(offsets.shape) == 1: +offsets = offsets[np.newaxis,:] # Make it Nx2. +#This decision is based on how they are initialized above +if self._uniform_offsets is None: +self._offsets = offsets +else: +self._uniform_offsets = offsets + +def get_offsets(self): +""" +Return the offsets for the collection. +""" +#This decision is based on how they are initialized above in __init__() +if self._uniform_offsets is None: +return self._offsets +else: +return self._uniform_offsets + def set_linewidths(self, lw): """ Set the linewidth(s) for the collection. *lw* can be a scalar - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Masked arrays in Quiver/Windbarbs
Ryan May wrote: > 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, There is no magic; we are not compressing or otherwise extracting the valid values, but are leaving the masking of U and V in place through the creation of the arrow vertices. It is the PolyCollection.draw() method that is then handling the masking. Now, having said that, and having traced through the code, I am not at all sure that everything in collections is still working correctly as described; I will have to look a bit more. Note that the path module itself can handle masking now, so masked arrays sometimes get passed all the way through to it. Quiver and windbarb could use the axes.delete_masked_points function right at the start, and this might be a good change to make, except that it is inconsistent with using the present set_UVC method to update arrows at constant locations. Eric - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Empty wind barb suggestion
Ryan May wrote: > Hi, > > In trying to add a symbol for an empty wind barb, I ran into problem. > Traditionally, a smaller, non-filled circle is used for low wind speeds > when doing a barb plot. I can draw the circle easily as a polygon, > using CirclePolygon from patches, but unfortunately, the fill color for > this polygon ends up being the same as the color of the flags on the > barbs. Therefore, as currently implemented, the only way to have > unfilled circles is to have unfilled flags. > > The only technical solution I can think of here is to have separate > collections for the circles and the polygons. Unfortunately, I have no > idea how to begin to do that within a class that inherits from > collections. Another option would be to somehow manually set the fill > colors on the circles after the collection is initialized. Anyone have > suggestions on how to make this work, or maybe a better technical solution. Ryan, Yes, this would require some bigger changes. Instead of inheriting from PolyCollection, it would have to contain two collections, or a collection and a Line2D with markers. An alternative would be to override the PolyCollection.draw() method with a near-copy, but with logic added right before the renderer call to set the alpha (column 3) of the rgba array to zero for the circles. A better way might be to modify the original draw method to use self.get_facecolors() instead of self._facecolors; then one could override the get_facecolors method, which would require much less code. Eric > > Jeff, how aesthetically displeasing do you think it would be to have > small (possibly colored) circles to represent the low winds instead of > the traditional (somewhat larger) hollow circle? It would make it > impossible to do sky cover in a traditional surface map, but maybe > Z-ordering could be used to hack around it. > > Thoughts, > > Ryan > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Progress on interactive backend detection
Ryan May wrote: > John Hunter wrote: >> Fernando and Gael proposed supporting a backend fallback option so the >> user could express the intention: use my default backend unless I >> happen to be in an incompatible user interface environment and then >> just choose the most sensible thing. Users who do not want this magic >> can simply turn the fallback option off. This behavior will only be >> triggered if >> >> 1) the fallback option is on (it will be by default) >> 2) the user is running mpl in an environment in which a user >> interface already has a running mainloop >> 3) the default backend is known to be incompatible. Eg, if the >> default backend is PS, nothing will happen. >> >> I think the proposed changes are reasonable. >> > +1 I agree. Sounds like progress. Eric > > Ryan > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Masked arrays in Quiver/Windbarbs
Eric Firing wrote: > Ryan May wrote: >> 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? >> > There is no magic; we are not compressing or otherwise extracting the > valid values, but are leaving the masking of U and V in place through > the creation of the arrow vertices. It is the PolyCollection.draw() > method that is then handling the masking. > > Now, having said that, and having traced through the code, I am not at > all sure that everything in collections is still working correctly as > described; I will have to look a bit more. > > Note that the path module itself can handle masking now, so masked > arrays sometimes get passed all the way through to it. So you mean the list/array of vertices can contain masked values? > > Quiver and windbarb could use the axes.delete_masked_points function > right at the start, and this might be a good change to make, except that > it is inconsistent with using the present set_UVC method to update > arrows at constant locations. delete_masked_points() looks to me like a sane way to go. I'll update my masked handling to use this. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
Jeff Whitaker wrote: > 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? It was for me. That's why I wrote scikits.delaunay in the first place. That, and the nngridr code's an uncommented mass of nested ifs. -- 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Can I update symbol positions and colors in a collection?
John Hunter wrote: On Thu, Jul 17, 2008 at 10:28 PM, Ryan May <[EMAIL PROTECTED]> wrote: I helped Eric out with this offline, and obviously set_array is for the colors, but the only solution we could come up with was to directly reset the PolyCollection._offsets member. This seems a little hacky. Is there any reason that there is not an set_offsets() (or something like it)? Any reason why I shouldn't code up a patch? No, I can't thing of any reason why this attribute should not be publicly settable, so patch away. Here's an updated version of the patch so that the doctring actually makes sense. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma --- collections.py (revision 5792) +++ collections.py (working copy) @@ -222,6 +222,32 @@ def set_pickradius(self,pickradius): self.pickradius = 5 def get_pickradius(self): return self.pickradius +def set_offsets(self, offsets): +""" +Set the offsets for the collection. *offsets* should be a +sequence. + +ACCEPTS: a sequence of pairs of floats +""" +offsets = np.asarray(offsets, np.float_) +if len(offsets.shape) == 1: +offsets = offsets[np.newaxis,:] # Make it Nx2. +#This decision is based on how they are initialized above +if self._uniform_offsets is None: +self._offsets = offsets +else: +self._uniform_offsets = offsets + +def get_offsets(self): +""" +Return the offsets for the collection. +""" +#This decision is based on how they are initialized above in __init__() +if self._uniform_offsets is None: +return self._offsets +else: +return self._uniform_offsets + def set_linewidths(self, lw): """ Set the linewidth(s) for the collection. *lw* can be a scalar - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Can I update symbol positions and colors in a collection?
Ryan, Thanks. I will take care of this one way or another, but I want to see whether we really need both _uniform_offsets and _offsets. Eric Ryan May wrote: > John Hunter wrote: >> On Thu, Jul 17, 2008 at 10:28 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> >>> I helped Eric out with this offline, and obviously set_array is for the >>> colors, but the only solution we could come up with was to directly >>> reset the PolyCollection._offsets member. This seems a little hacky. >>> Is there any reason that there is not an set_offsets() (or something >>> like it)? Any reason why I shouldn't code up a patch? >> >> No, I can't thing of any reason why this attribute should not be >> publicly settable, so patch away. > > Here's an updated version of the patch so that the doctring actually > makes sense. > > Ryan > > > > > - > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Masked arrays in Quiver/Windbarbs
Ryan May wrote: > Eric Firing wrote: >> Ryan May wrote: >>> 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? > >> >> There is no magic; we are not compressing or otherwise extracting the >> valid values, but are leaving the masking of U and V in place through >> the creation of the arrow vertices. It is the PolyCollection.draw() >> method that is then handling the masking. >> >> Now, having said that, and having traced through the code, I am not >> at all sure that everything in collections is still working correctly >> as described; I will have to look a bit more. >> >> Note that the path module itself can handle masking now, so masked >> arrays sometimes get passed all the way through to it. > > So you mean the list/array of vertices can contain masked values? Yes. But again, trying to trace data values through various paths in the code, it can be hard to keep track of what assumptions are being made at each stage. I think the present intention is that masked values are passed through, but I also think I saw a recent code addition (maybe...) that does not do this. I need to check. > >> >> Quiver and windbarb could use the axes.delete_masked_points function >> right at the start, and this might be a good change to make, except >> that it is inconsistent with using the present set_UVC method to >> update arrows at constant locations. > > delete_masked_points() looks to me like a sane way to go. I'll update > my masked handling to use this. It can be OK if your windbarb is intended as a one-shot instance--that is, the user makes another one if the data change--which is probably OK. delete_masked_points looks to me like it has its own problems in the whole mpl-with-units context, including a recent change that I suspect breaks the handling of datetime inputs, but I don't think that any changes or cleanups will affect your use of it. Eric > > Ryan > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Masked arrays in Quiver/Windbarbs
Eric Firing wrote: >>> Quiver and windbarb could use the axes.delete_masked_points function >>> right at the start, and this might be a good change to make, except >>> that it is inconsistent with using the present set_UVC method to >>> update arrows at constant locations. >> >> delete_masked_points() looks to me like a sane way to go. I'll update >> my masked handling to use this. > > It can be OK if your windbarb is intended as a one-shot instance--that > is, the user makes another one if the data change--which is probably OK. > > delete_masked_points looks to me like it has its own problems in the > whole mpl-with-units context, including a recent change that I suspect > breaks the handling of datetime inputs, but I don't think that any > changes or cleanups will affect your use of it. What I've tried to do is keep copies of the original data passed in, and when updating UV or offsets, use delete_masked_points to keep them lined up as appropriate. Does this sound reasonable? It doesn't look too bad, and still keeps an interface that allows updating. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Can I update symbol positions and colors in a collection?
Thanks for the help, Ryan and Eric. On Sat, Jul 19, 2008 at 7:27 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > Ryan, > > Thanks. I will take care of this one way or another, but I want to see > whether we really need both _uniform_offsets and _offsets. > > Eric > > Ryan May wrote: >> John Hunter wrote: >>> On Thu, Jul 17, 2008 at 10:28 PM, Ryan May <[EMAIL PROTECTED]> wrote: >>> I helped Eric out with this offline, and obviously set_array is for the colors, but the only solution we could come up with was to directly reset the PolyCollection._offsets member. This seems a little hacky. Is there any reason that there is not an set_offsets() (or something like it)? Any reason why I shouldn't code up a patch? >>> >>> No, I can't thing of any reason why this attribute should not be >>> publicly settable, so patch away. >> >> Here's an updated version of the patch so that the doctring actually >> makes sense. >> >> Ryan >> - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Masked arrays in Quiver/Windbarbs
Eric Firing wrote: > Ryan May wrote: > >> Eric Firing wrote: >> >>> Ryan May wrote: >>> 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? >> >> >> >>> There is no magic; we are not compressing or otherwise extracting the >>> valid values, but are leaving the masking of U and V in place through >>> the creation of the arrow vertices. It is the PolyCollection.draw() >>> method that is then handling the masking. >>> >>> Now, having said that, and having traced through the code, I am not >>> at all sure that everything in collections is still working correctly >>> as described; I will have to look a bit more. >>> >>> Note that the path module itself can handle masking now, so masked >>> arrays sometimes get passed all the way through to it. >>> >> So you mean the list/array of vertices can contain masked values? >> > > Yes. But again, trying to trace data values through various paths in > the code, it can be hard to keep track of what assumptions are being > made at each stage. I think the present intention is that masked values > are passed through, but I also think I saw a recent code addition > (maybe...) that does not do this. I need to check. > > >>> Quiver and windbarb could use the axes.delete_masked_points function >>> right at the start, and this might be a good change to make, except >>> that it is inconsistent with using the present set_UVC method to >>> update arrows at constant locations. >>> >> delete_masked_points() looks to me like a sane way to go. I'll update >> my masked handling to use this. >> > > It can be OK if your windbarb is intended as a one-shot instance--that > is, the user makes another one if the data change--which is probably OK. > > delete_masked_points looks to me like it has its own problems in the > whole mpl-with-units context, including a recent change that I suspect > breaks the handling of datetime inputs, but I don't think that any > changes or cleanups will affect your use of it. I suspect that your concern may be referring to my recent change. I started some unit tests for delete_masked_points() (in unit/axes_unit.py) when I made the modifications, so if you have use cases, put 'em in there... -Andrew - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] reverting changes to contour.py
David,
I am reverting your changes to contour.py; that is, I am taking it back
to 5689. The problem is that running contour_demo.py, below, fails.
Some index accounting somewhere is getting fouled up. I don't have time
to investigate.
When you have it straightened out you can put the changes back, so this
is just a brief setback.
We might want to consider, however, whether such extensive changes
should be made immediately *before* a "bugfix" release. I think John is
trying to get one out. I am already a little nervous about other recent
and impending changes in this context. (Your idea of a branch was a
good one in concept, but maybe a pain and more trouble than it is worth
with svn. Too bad we aren't using something nice like Mercurial. Now,
that comment should push a few buttons.)
Eric
In [1]:run contour_demo.py
---
IndexErrorTraceback (most recent call last)
/home/efiring/programs/py/mpl/mpl_trunk/examples/pylab_examples/contour_demo.py
in ()
82inline=1,
83fmt='%1.1f',
---> 84fontsize=14)
85
86 # make a colorbar for the contour lines
/usr/local/lib/python2.5/site-packages/matplotlib/pyplot.pyc in
clabel(*args, **kwargs)
1698 hold(h)
1699 try:
-> 1700 ret = gca().clabel(*args, **kwargs)
1701 draw_if_interactive()
1702 except:
/usr/local/lib/python2.5/site-packages/matplotlib/axes.pyc in
clabel(self, CS, *args, **kwargs)
5996
5997 def clabel(self, CS, *args, **kwargs):
-> 5998 return CS.clabel(*args, **kwargs)
5999 clabel.__doc__ = mcontour.ContourSet.clabel.__doc__
6000
/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in
clabel(self, *args, **kwargs)
150 blocking_contour_labeler(inline)
151 else:
--> 152 self.labels(inline)
153
154 self.label_list = cbook.silent_list('text.Text', self.cl)
/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in
labels(self, inline)
451 if self.print_label(slc,lw):
452 x,y, rotation, ind =
self.locate_label(slc, lw)
--> 453 self.add_label(x,y,rotation,icon)
454
455 if inline:
/usr/local/lib/python2.5/site-packages/matplotlib/contour.pyc in
add_label(self, x, y, rotation, icon)
364 verticalalignment='center')
365
--> 366 color =
self.label_mappable.to_rgba(self.label_cvalues[icon],
367 alpha=self.alpha)
368
IndexError: index out of bounds
>
/usr/local/lib/python2.5/site-packages/matplotlib/contour.py(366)add_label()
365
--> 366 color =
self.label_mappable.to_rgba(self.label_cvalues[icon],
367 alpha=self.alpha)
ipdb> icon
7
ipdb> self.label_cvalues
array([-1. , -0.6, -0.2, 0.2, 0.6, 1. , 1.4])
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Circular import
Hi, In integrating my barbs work, I'm having trouble that causes a circular import. I used delete_masked_points from axes. The problem here is that axes imports quiver (where I put barbs) which then has to (in some form) import axes to get delete_masked_points. Anyone have something I'm missing here? Or can I move delete_masked_points to a better location? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > In integrating my barbs work, I'm having trouble that causes a circular > import. I used delete_masked_points from axes. The problem here is that > axes imports quiver (where I put barbs) which then has to (in some form) > import axes to get delete_masked_points. Anyone have something I'm > missing here? Or can I move delete_masked_points to a better location? mlab or cbook would be fine 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
John Hunter wrote: > On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> Hi, >> >> In integrating my barbs work, I'm having trouble that causes a circular >> import. I used delete_masked_points from axes. The problem here is that >> axes imports quiver (where I put barbs) which then has to (in some form) >> import axes to get delete_masked_points. Anyone have something I'm >> missing here? Or can I move delete_masked_points to a better location? > > mlab or cbook would be fine > cbook seems like a better home for utility functions like this. Eric - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
John Hunter wrote:
On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <[EMAIL PROTECTED]> wrote:
Hi,
In integrating my barbs work, I'm having trouble that causes a circular
import. I used delete_masked_points from axes. The problem here is that
axes imports quiver (where I put barbs) which then has to (in some form)
import axes to get delete_masked_points. Anyone have something I'm
missing here? Or can I move delete_masked_points to a better location?
mlab or cbook would be fine
JDH
Here's a patch to do just that.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--- axes.py (revision 5793)
+++ axes.py (working copy)
@@ -31,45 +31,6 @@
is_string_like = cbook.is_string_like
-def delete_masked_points(*args):
-"""
-Find all masked points in a set of arguments, and return
-the arguments with only the unmasked points remaining.
-
-This will also delete any points that are not finite (nan or inf).
-
-The overall mask is calculated from any masks that are present.
-If a mask is found, any argument that does not have the same
-dimensions is left unchanged; therefore the argument list may
-include arguments that can take string or array values, for
-example.
-
-Array arguments must have the same length; masked arguments must
-be one-dimensional.
-
-Written as a helper for scatter, but may be more generally
-useful.
-"""
-masks = [ma.getmaskarray(x) for x in args if hasattr(x, 'mask')]
-isfinite = [np.isfinite(x) for x in args]
-masks.extend( [~x for x in isfinite if not isinstance(x,types.NotImplementedType)] )
-if len(masks) == 0:
-return args
-mask = reduce(np.logical_or, masks)
-margs = []
-for x in args:
-if (not is_string_like(x)
-and iterable(x)
-and len(x) == len(mask)):
-if (hasattr(x, 'get_compressed_copy')):
-compressed_x = x.get_compressed_copy(mask)
-else:
-compressed_x = ma.masked_array(x, mask=mask).compressed()
-margs.append(compressed_x)
-else:
-margs.append(x)
-return margs
-
def _process_plot_format(fmt):
"""
Process a matlab(TM) style color/line style format string. Return a
@@ -4827,7 +4788,7 @@
self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)
-x, y, s, c = delete_masked_points(x, y, s, c)
+x, y, s, c = cbook.delete_masked_points(x, y, s, c)
# The inherent ambiguity is resolved in favor of color
# mapping, not interpretation as rgb or rgba.
@@ -5091,7 +5052,7 @@
self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)
-x, y = delete_masked_points(x, y)
+x, y = cbook.delete_masked_points(x, y)
# Set the size of the hexagon grid
if iterable(gridsize):
--- cbook.py (revision 5793)
+++ cbook.py (working copy)
@@ -1165,8 +1165,46 @@
else:
os.remove(path)
+def delete_masked_points(*args):
+"""
+Find all masked points in a set of arguments, and return
+the arguments with only the unmasked points remaining.
+This will also delete any points that are not finite (nan or inf).
+The overall mask is calculated from any masks that are present.
+If a mask is found, any argument that does not have the same
+dimensions is left unchanged; therefore the argument list may
+include arguments that can take string or array values, for
+example.
+
+Array arguments must have the same length; masked arguments must
+be one-dimensional.
+
+Written as a helper for scatter, but may be more generally
+useful.
+"""
+masks = [ma.getmaskarray(x) for x in args if hasattr(x, 'mask')]
+isfinite = [np.isfinite(x) for x in args]
+masks.extend( [~x for x in isfinite if not isinstance(x,types.NotImplementedType)] )
+if len(masks) == 0:
+return args
+mask = reduce(np.logical_or, masks)
+margs = []
+for x in args:
+if (not is_string_like(x)
+and iterable(x)
+and len(x) == len(mask)):
+if (hasattr(x, 'get_compressed_copy')):
+compressed_x = x.get_compressed_copy(mask)
+else:
+compressed_x = ma.masked_array(x, mask=mask).compressed()
+margs.append(compressed_x)
+else:
+margs.append(x)
+return margs
+
+
# a dict to cross-map linestyle arguments
_linestyles = [('-', 'solid'),
('--', 'dashed'),
-
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
Re: [matplotlib-devel] Circular import
John Hunter wrote: On Sat, Jul 19, 2008 at 8:58 PM, Ryan May <[EMAIL PROTECTED]> wrote: Hi, In integrating my barbs work, I'm having trouble that causes a circular import. I used delete_masked_points from axes. The problem here is that axes imports quiver (where I put barbs) which then has to (in some form) import axes to get delete_masked_points. Anyone have something I'm missing here? Or can I move delete_masked_points to a better location? mlab or cbook would be fine JDH Take this one instead. I missed some imports on the last one (oops). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma --- axes.py (revision 5793) +++ axes.py (working copy) @@ -1,5 +1,5 @@ from __future__ import division, generators -import math, sys, warnings, datetime, new, types +import math, sys, warnings, datetime, new import numpy as np from numpy import ma @@ -31,45 +31,6 @@ is_string_like = cbook.is_string_like -def delete_masked_points(*args): -""" -Find all masked points in a set of arguments, and return -the arguments with only the unmasked points remaining. - -This will also delete any points that are not finite (nan or inf). - -The overall mask is calculated from any masks that are present. -If a mask is found, any argument that does not have the same -dimensions is left unchanged; therefore the argument list may -include arguments that can take string or array values, for -example. - -Array arguments must have the same length; masked arguments must -be one-dimensional. - -Written as a helper for scatter, but may be more generally -useful. -""" -masks = [ma.getmaskarray(x) for x in args if hasattr(x, 'mask')] -isfinite = [np.isfinite(x) for x in args] -masks.extend( [~x for x in isfinite if not isinstance(x,types.NotImplementedType)] ) -if len(masks) == 0: -return args -mask = reduce(np.logical_or, masks) -margs = [] -for x in args: -if (not is_string_like(x) -and iterable(x) -and len(x) == len(mask)): -if (hasattr(x, 'get_compressed_copy')): -compressed_x = x.get_compressed_copy(mask) -else: -compressed_x = ma.masked_array(x, mask=mask).compressed() -margs.append(compressed_x) -else: -margs.append(x) -return margs - def _process_plot_format(fmt): """ Process a matlab(TM) style color/line style format string. Return a @@ -4827,7 +4788,7 @@ self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs) -x, y, s, c = delete_masked_points(x, y, s, c) +x, y, s, c = cbook.delete_masked_points(x, y, s, c) # The inherent ambiguity is resolved in favor of color # mapping, not interpretation as rgb or rgba. @@ -5091,7 +5052,7 @@ self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs) -x, y = delete_masked_points(x, y) +x, y = cbook.delete_masked_points(x, y) # Set the size of the hexagon grid if iterable(gridsize): --- cbook.py (revision 5793) +++ cbook.py (working copy) @@ -3,9 +3,10 @@ from the Python Cookbook -- hence the name cbook """ from __future__ import generators -import re, os, errno, sys, StringIO, traceback, locale, threading +import re, os, errno, sys, StringIO, traceback, locale, threading, types import time, datetime import numpy as np +from numpy import ma from weakref import ref major, minor1, minor2, s, tmp = sys.version_info @@ -1165,8 +1166,46 @@ else: os.remove(path) +def delete_masked_points(*args): +""" +Find all masked points in a set of arguments, and return +the arguments with only the unmasked points remaining. +This will also delete any points that are not finite (nan or inf). +The overall mask is calculated from any masks that are present. +If a mask is found, any argument that does not have the same +dimensions is left unchanged; therefore the argument list may +include arguments that can take string or array values, for +example. + +Array arguments must have the same length; masked arguments must +be one-dimensional. + +Written as a helper for scatter, but may be more generally +useful. +""" +masks = [ma.getmaskarray(x) for x in args if hasattr(x, 'mask')] +isfinite = [np.isfinite(x) for x in args] +masks.extend( [~x for x in isfinite if not isinstance(x,types.NotImplementedType)] ) +if len(masks) == 0: +return args +mask = reduce(np.logical_or, masks) +margs = [] +for x in args: +if (not is_string_like(x) +and iterable(x) +and len(x) == len(mask)): +if (hasattr(x, 'get_compressed_copy')): +compressed_x = x.get_compressed_copy(mask) +else: +compressed_x = ma.masked_array(x, mask=mask).compressed() +margs.ap
Re: [matplotlib-devel] reverting changes to contour.py
On Sat, Jul 19, 2008 at 8:02 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > We might want to consider, however, whether such extensive changes > should be made immediately *before* a "bugfix" release. I think John is > trying to get one out. I am already a little nervous about other recent > and impending changes in this context. (Your idea of a branch was a Although I may have used the phrase "bugfix release" many times in the past, I want to clarify my thinking on this. I distinguish between point releases and major releases. With the exception of the maintenance branch, on which the *only* changes should be bugfixes, I expect every point release to have new features and bugfixes. When we decide to bump the major version is of course subjective, but it normally comes when a number of significant features have been introduced, and it should be comparatively rare, 2 to 4 times a year or so. But I expect and want new features in every point release. We are fortunate that we have a lot of developers, and Charlie is a very responsive release manager. I would rather err on the side of getting new features out, tested to the best of our abilities, with the understanding that if we break something important we will roll out a point release that fixes a critical bug within 12 to 24 hours, and hide the broken release in the mean time. Release early, release often. My aversion to branches stems not from the weaknesses in svn merge, which may be better in hg or other version control systems. The reason I wnat people contributing to the trunk is that I want as many people testing and using the code as possible so we can find and fix the bugs before they are released. While Michael's transforms refactoring was so significant that it absolutely required a branch, we did not start finding the bugs until we made his branch the trunk, and even then did not find the bulk of them. We found them when we released the code. More tests will help, and we should have as many tests as we can muster, but until we have bullet-proof tests we have to leverage our developers and users as testers. The only short term pressure for a point release is coming from debian, because they are having some trouble with our last point release. Because debian is an important platform, I want to get a point release out that satisfies their problems ASAP, but not before we are ready. Whether this is next week or next month or next year will depend on whether the code is ready (I hear echos of Orson Welles in the old Paul Masson commercial, "We will sell no wine, before it's time"). In the case of the contouring enhancements, they're not ready, so we'll wait. In the situation where debian or some other important vendor has a freeze deadline with a critical problem that needs fixing, we can always do a branch off the last point release that fixes just the required bugs. Sandro can keep us appraised if such a deadline is approaching for 0.98.2. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
On Sat, Jul 19, 2008 at 9:30 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Take this one instead. I missed some imports on the last one (oops). Hey Ryan -- the code you have been contributing is certainly high quality, and I am happy to give you commit rights if you send me your sf id. You should still post here for anything significant so we can review and provide input/feedback, but we'd be happy to have you making contributions directly. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
John Hunter wrote: > On Sat, Jul 19, 2008 at 9:30 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> Take this one instead. I missed some imports on the last one (oops). > > Hey Ryan -- the code you have been contributing is certainly high > quality, and I am happy to give you commit rights if you send me your > sf id. You should still post here for anything significant so we can > review and provide input/feedback, but we'd be happy to have you > making contributions directly. Ok, thanks for the vote of confidence. My (newly created) ID is: ryanmay Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular import
On Sat, Jul 19, 2008 at 9:48 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Ok, thanks for the vote of confidence. My (newly created) ID is: ryanmay Alright, you're now set up for commits. Keep working closely with Eric and Jeff and the rest of us on the functionality you are adding. Welcome aboard! 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
