From tcaswell at gmail.com Tue Sep 1 04:26:14 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 01 Sep 2015 02:26:14 +0000 Subject: [Matplotlib-devel] matplotlib twitter handle Message-ID: Hello all, Ben asked about this a while ago and go not response, but does anyone control the @matplotlib twitter account (https://twitter.com/matplotlib)? If I don't hear back in a few days I am going to start the twitter protocol for re-claiming a name that someone is squatting on. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Thu Sep 3 23:44:02 2015 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Thu, 3 Sep 2015 14:44:02 -0700 Subject: [Matplotlib-devel] setting 'mathtext.fontset' appears to have no effect Message-ID: I've been playing with setting matplotlib.rcParams['mathtext.fontset'. As far as I can tell, the value of this parameter has absolutely no effect. Is this a known issue? My code is attached. Phillip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: equation1.py Type: application/octet-stream Size: 959 bytes Desc: not available URL: From juichenieder-nabb at yahoo.co.uk Sat Sep 5 17:16:06 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sat, 05 Sep 2015 17:16:06 +0200 Subject: [Matplotlib-devel] MEP 29 Axes Refactor Message-ID: <55EB0736.7090607@yahoo.co.uk> Dear matplotlibers, Here I announce the creation of MEP29 to tidy up the Axes classes, and other classes that relate specifically to the Axes. See https://github.com/matplotlib/matplotlib/pull/5029 which you can click through to https://github.com/OceanWolf/matplotlib/blob/MEP-Axes-API/doc/devel/MEP/MEP29.rst to see the text itself. This MEP outlines how I see the Axes class progressing and tbh I feel very excited about what I have written, allowing people to write all sorts of exotic Axes such as those that employ non-Euclidian geometry; and also allowing for us to add multiple x,y,z axes to a 3d plot to name but a few of the features this MEP will add. Check out the MEP for more details, and please feel free to give comment. I should also point out that while I know about the existence of non-Euclidian geometry, my background comes from ocean-physics, not mathematics, so I have no knowledge beyond that considered popular mathematics. Also due to the complexity of the Axes classes at the moment, and how it spreads out into many files and beyond the core-matplotlib, I think this will take quite some time to implement, at the moment I just want to collate the most salient points into this MEP, I don't know how many features unknown to me exist, so help welcome, and then sort through, decide on a stratagy of how to split this up into more bitesized PRs and get going. Best, OceanWolf From joferkington at gmail.com Sat Sep 5 19:25:51 2015 From: joferkington at gmail.com (Joe Kington) Date: Sat, 5 Sep 2015 12:25:51 -0500 Subject: [Matplotlib-devel] MEP 29 Axes Refactor In-Reply-To: <55EB0736.7090607@yahoo.co.uk> References: <55EB0736.7090607@yahoo.co.uk> Message-ID: First off, I don't intend this to come across as overly critical! I think this is a very good discussion to have. Also, I tend to have a bad "knee-jerk" reaction to change and tend to come around over time, so keep that in mind too. :) However, while I agree that `Axes` is quite a beast, I'm not sure this proposal simplifies things. From my perspective, it adds complexity. If I'm understanding correctly, this would effectively tie the Transform stack to the Axes, instead of having the Axes generate a Transform object that may or may not be used by the artists in the Axes. First we define our coordinate transformation functions: axes_to_base(self, > *q) base_to_axes(self, x, y) > > The term base could get replaced with screen but for now we will keep it > simple to reflect another transformation from base coords to screen coords, > e.g. perhaps to differentiate between window and screen coords. > This is my main concern. We have a (i.m.o.) very flexible and actually quite clean Transform system to handle this. Why shift away from it? `ax.transData` may be non-PEP8 naming, but it's a good way to do this. The concept of having Transform objects that handle this but are separate from the Axes gives a lot of flexibility. In my opinion, the core concept of having this transformation handled by a Transform object that's separate from the Axes is one of the best things about matplotlib's design. Or am I misunderstanding, and this is just a refactoring of `_get_core_transform` and `_get_affine_transform` into one method? --------------------- My other main concern centers on map projections. The MEP currently mentions: an anticipated structure of a base mapping class with a coordinate system > in lat/lon coordinates, but with different mapping projections available > for the conversion between the Axes coordinate system and the screen. > However, this is a bad approach for cartographic data. Geographic is not the base for a projected coordinate system. There are several reasons for that. 1. Map data is usually _in the projected coordinate system_. Lat, long data is actually not terribly common unless you're working with global datasets. 2. Raster data (i.e. anything displayed with imshow) is typically going to be gridded on a regular grid in the projected coordinate system. Forcing a transformation back to a non-uniform grid in lat, long space then back onto a different uniform grid than the original in display space is unnecessarily expensive. One of the great things about Cartopy is that it leaves the fundamental Cartesian projected space unchanged, and let's you specify the transform if you want to use geographic coordinates. Basemap handles it a bit differently but has the same core concept. Latitudes and longitudes aren't the data coordinate system. The projected coordinate system is. There's a reason for that approach. Forcing people to convert their data into a geographic coordinate system before plotting it is a bad idea. It's good to have plotting methods that allow geographic coordinates, but bad to require that transformation. (I'll skip the very important datum part for the moment. Just be aware that a lat, long only gets you to within ~1km of a location without more information.) ---------------- At any rate, I may very well have misunderstood the changes that are being proposed here! My apologies if I have. Cheers, -Joe On Sat, Sep 5, 2015 at 10:16 AM, OceanWolf wrote: > Dear matplotlibers, > Here I announce the creation of MEP29 to tidy up the Axes classes, and > other classes that relate specifically to the Axes. > > See https://github.com/matplotlib/matplotlib/pull/5029 which you can > click through to > https://github.com/OceanWolf/matplotlib/blob/MEP-Axes-API/doc/devel/MEP/MEP29.rst > to see the text itself. > > This MEP outlines how I see the Axes class progressing and tbh I feel very > excited about what I have written, allowing people to write all sorts of > exotic Axes such as those that employ non-Euclidian geometry; and also > allowing for us to add multiple x,y,z axes to a 3d plot to name but a few > of the features this MEP will add. > > Check out the MEP for more details, and please feel free to give comment. > I should also point out that while I know about the existence of > non-Euclidian geometry, my background comes from ocean-physics, not > mathematics, so I have no knowledge beyond that considered popular > mathematics. > > Also due to the complexity of the Axes classes at the moment, and how it > spreads out into many files and beyond the core-matplotlib, I think this > will take quite some time to implement, at the moment I just want to > collate the most salient points into this MEP, I don't know how many > features unknown to me exist, so help welcome, and then sort through, > decide on a stratagy of how to split this up into more bitesized PRs and > get going. > > Best, > OceanWolf > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Sat Sep 5 22:10:51 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sat, 05 Sep 2015 22:10:51 +0200 Subject: [Matplotlib-devel] MEP 29 Axes Refactor In-Reply-To: References: <55EB0736.7090607@yahoo.co.uk> Message-ID: <55EB4C4B.6090902@yahoo.co.uk> Not too sure what you meant by ````. On 05/09/15 19:25, Joe Kington wrote: > > First off, I don't intend this to come across as overly critical! I > think this is a very good discussion to have. > Also, I tend to have a bad "knee-jerk" reaction to change and tend to > come around over time, so keep that in mind too. :) No worries, I experience the same, and yes I wanted to open this up for just this kind of interrogation, especially as we have a lot of axes related code, and I have only touched a fraction of it to date. To explain where I come from, I should say that I like to work bottom-up. I find designing good code starts with asking probing questions about what you want to model, in this case we have an ``_AxesBase`` class and so by definition it should model an abstract Axes, because of this in the "Detailed Description" of this MEP I begin by asking the question probing the definition of an Axes. I believe that if we model the world intutitively as we see it, everything else will fall into place. I find the most direct route in code usually contains lots of inflexibility, like building a road through the mountain, you might go the direct route, but it becomes very difficult to maintain and expand upon. Hence the focus lies in the journey. > > However, while I agree that `Axes` is quite a beast, I'm not sure this > proposal simplifies things. From my perspective, it adds complexity. > If I'm understanding correctly, this would effectively tie the > Transform stack to the Axes, instead of having the Axes generate a > Transform object that may or may not be used by the artists in the Axes. > If I understand you correctly you don't like the idea of forcing Artists to use the transform. I don't see this as a problem (at the moment). As far as I see it, all coordinates supplied to an Artist will come in the form of Axes coordinates, i.e. Axes space, and thus we need to transform those coordinates to screen coordinates... at least at some point, probably when it comes to drawing... I especially think of drawing a triangle onto a spherical geometry, see https://en.wikipedia.org/wiki/Spherical_geometry. We create a Polygon patch and supply the three vertices that define our Triangle... however on a spherical geometry, these "straight" lines do not conform to the Euclid definition of straight, we need to draw them curved. Because of this the transform will need to come very late in the drawing process. > > First we define our coordinate transformation functions: > axes_to_base(self, *q) base_to_axes(self, x, y) > > The term |base| could get replaced with |screen| but for now we > will keep it simple to reflect another transformation from base > coords to screen coords, e.g. perhaps to differentiate between > window and screen coords. > > > This is my main concern. We have a (i.m.o.) very flexible and > actually quite clean Transform system to handle this. Why shift away > from it? `ax.transData` may be non-PEP8 naming, but it's a good way to > do this. The concept of having Transform objects that handle this but > are separate from the Axes gives a lot of flexibility. In my opinion, > the core concept of having this transformation handled by a Transform > object that's separate from the Axes is one of the best things about > matplotlib's design. > > Or am I misunderstanding, and this is just a refactoring of > `_get_core_transform` and `_get_affine_transform` into one method? > As far as I know, I want to keep the transform system. I think I do just mean refactoring that into one method. I say think as I still don't feel fully understand how it all works, the Transform system, brilliant, but very mind-boggling. I had to delve into it to find a bug reported by a user on github, and went through around 50 (perhaps more) Transform operations before I got to the problem. If you need to debug part of it, like i had to, it becomes a tangled mess, luckily for most people they don't have to, and the usage works quite simply. When I tracked down the bug I also spent quite some time trying to figure out the Transform classes, prior to the bug I only knew of Rotation, Shear and Reflection Transforms. Anyway my point here comes that while great, it can become quite the head-ache for the average user developer, especially for those who know even less then I do about transforms, and so I want to blackbox the transforms in the Axes with simple names such as axes_to_***_coords(self, *q), and ***_to_axes_coords(self, x, y). So I want to make it easy for people to write their own axes with their own transform methods without having to worry about how the rest of the Artist code and plot methods work (unless it works really bizarrely); and I want people to work on Artist code, and creating their own tools and user interaction stuff without having to worry about learning about transforms (they just need to know that these two methods will do the conversion for them from data coordinates, which they understand, to the location on the screen or whatever, which they will also understand, start talking about AffineTransforms and I think we will scare people off). > --------------------- > > My other main concern centers on map projections. The MEP currently > mentions: > > an anticipated structure of a base mapping class with a coordinate > system in lat/lon coordinates, but with different mapping > projections available for the conversion between the Axes > coordinate system and the screen. > > > However, this is a bad approach for cartographic data. Geographic is > not the base for a projected coordinate system. There are several > reasons for that. > > 1. Map data is usually _in the projected coordinate system_. Lat, > long data is actually not terribly common unless you're working with > global datasets. > 2. Raster data (i.e. anything displayed with imshow) is typically > going to be gridded on a regular grid in the projected coordinate > system. Forcing a transformation back to a non-uniform grid in lat, > long space then back onto a different uniform grid than the original > in display space is unnecessarily expensive. > > One of the great things about Cartopy is that it leaves the > fundamental Cartesian projected space unchanged, and let's you specify > the transform if you want to use geographic coordinates. Basemap > handles it a bit differently but has the same core concept. Latitudes > and longitudes aren't the data coordinate system. The projected > coordinate system is. > > There's a reason for that approach. Forcing people to convert their > data into a geographic coordinate system before plotting it is a bad > idea. It's good to have plotting methods that allow geographic > coordinates, but bad to require that transformation. (I'll skip the > very important datum part for the moment. Just be aware that a lat, > long only gets you to within ~1km of a location without more information.) Hmm, when I have used Basemap, the data files I work with I always get in lat/lon format. One of my biggest annoyances with Basemap comes from having to work projection coordinates. I move the mouse over the map and statusbar shows me useless projection coordinate information; I want to rotate the globe (in 'ortho' projection), but I can't, it becomes very difficult to use from a user interface point of view. I think the solution here comes from using a dual approach. With the functions above I used the term base, as in the ``axes_to_base`` and ``base_to_axes`` functions. Here ``base`` defines the projected coordinates. We can then leave it up to the user to decide whether to plot in axes coordinates or base coordinates. We can start of leaving the axes side unimplemented, and perhaps we will never implement the axes side for some Axes classes... what do you think? Best, OceanWolf -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Sun Sep 6 00:58:09 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sun, 06 Sep 2015 00:58:09 +0200 Subject: [Matplotlib-devel] MEP 29 Axes Refactor In-Reply-To: <55EB4C4B.6090902@yahoo.co.uk> References: <55EB0736.7090607@yahoo.co.uk> <55EB4C4B.6090902@yahoo.co.uk> Message-ID: <55EB7381.9070708@yahoo.co.uk> Damn, forgot to delete the top part before I sent, I started writing at the top, before cutting and pasting to below and forgot to delete the rest. Anyway thank you again for your positive constructive criticism. As I say, exactly what I wanted, food for thought, use cases that I didn't know about that I can now research and feed into the "Detailed Description" section. I now see some more inconsistencies that we need to solve. I feel I came to quick in my last email to bring about solutions, possibly they will become the solution, perhaps not, but first I need to flesh out the description section... hopefully over the next week I will add information about the inconsistencies your email reply brought to light (I know I speak in riddles, but I have to first clarify it for myself with examples). The rest of the MEP will take time to develop, probably with some simple diagrams too. And when I say "I" feel free to interpret it as "we", if you have ideas please feel free to post them here, or make PRs, for example against my PR and we can flesh the Description section out even more :). Best OceanWolf On 05/09/15 22:10, OceanWolf wrote: > > > > > Not too sure what you meant by ````. > > > > On 05/09/15 19:25, Joe Kington wrote: >> >> First off, I don't intend this to come across as overly critical! I >> think this is a very good discussion to have. >> Also, I tend to have a bad "knee-jerk" reaction to change and tend to >> come around over time, so keep that in mind too. :) > No worries, I experience the same, and yes I wanted to open this up > for just this kind of interrogation, especially as we have a lot of > axes related code, and I have only touched a fraction of it to date. > > To explain where I come from, I should say that I like to work > bottom-up. I find designing good code starts with asking probing > questions about what you want to model, in this case we have an > ``_AxesBase`` class and so by definition it should model an abstract > Axes, because of this in the "Detailed Description" of this MEP I > begin by asking the question probing the definition of an Axes. I > believe that if we model the world intutitively as we see it, > everything else will fall into place. I find the most direct route in > code usually contains lots of inflexibility, like building a road > through the mountain, you might go the direct route, but it becomes > very difficult to maintain and expand upon. Hence the focus lies in > the journey. > >> >> However, while I agree that `Axes` is quite a beast, I'm not sure >> this proposal simplifies things. From my perspective, it adds >> complexity. If I'm understanding correctly, this would effectively >> tie the Transform stack to the Axes, instead of having the Axes >> generate a Transform object that may or may not be used by the >> artists in the Axes. >> > If I understand you correctly you don't like the idea of forcing > Artists to use the transform. I don't see this as a problem (at the > moment). As far as I see it, all coordinates supplied to an Artist > will come in the form of Axes coordinates, i.e. Axes space, and thus > we need to transform those coordinates to screen coordinates... at > least at some point, probably when it comes to drawing... I especially > think of drawing a triangle onto a spherical geometry, see > https://en.wikipedia.org/wiki/Spherical_geometry. We create a Polygon > patch and supply the three vertices that define our Triangle... > however on a spherical geometry, these "straight" lines do not conform > to the Euclid definition of straight, we need to draw them curved. > Because of this the transform will need to come very late in the > drawing process. >> >> First we define our coordinate transformation functions: >> axes_to_base(self, *q) base_to_axes(self, x, y) >> >> The term |base| could get replaced with |screen| but for now we >> will keep it simple to reflect another transformation from base >> coords to screen coords, e.g. perhaps to differentiate between >> window and screen coords. >> >> >> This is my main concern. We have a (i.m.o.) very flexible and >> actually quite clean Transform system to handle this. Why shift away >> from it? `ax.transData` may be non-PEP8 naming, but it's a good way >> to do this. The concept of having Transform objects that handle this >> but are separate from the Axes gives a lot of flexibility. In my >> opinion, the core concept of having this transformation handled by a >> Transform object that's separate from the Axes is one of the best >> things about matplotlib's design. >> >> Or am I misunderstanding, and this is just a refactoring of >> `_get_core_transform` and `_get_affine_transform` into one method? >> > As far as I know, I want to keep the transform system. I think I do > just mean refactoring that into one method. I say think as I still > don't feel fully understand how it all works, the Transform system, > brilliant, but very mind-boggling. I had to delve into it to find a > bug reported by a user on github, and went through around 50 (perhaps > more) Transform operations before I got to the problem. If you need > to debug part of it, like i had to, it becomes a tangled mess, luckily > for most people they don't have to, and the usage works quite simply. > When I tracked down the bug I also spent quite some time trying to > figure out the Transform classes, prior to the bug I only knew of > Rotation, Shear and Reflection Transforms. Anyway my point here comes > that while great, it can become quite the head-ache for the average > user developer, especially for those who know even less then I do > about transforms, and so I want to blackbox the transforms in the Axes > with simple names such as axes_to_***_coords(self, *q), and > ***_to_axes_coords(self, x, y). > > So I want to make it easy for people to write their own axes with > their own transform methods without having to worry about how the rest > of the Artist code and plot methods work (unless it works really > bizarrely); and I want people to work on Artist code, and creating > their own tools and user interaction stuff without having to worry > about learning about transforms (they just need to know that these two > methods will do the conversion for them from data coordinates, which > they understand, to the location on the screen or whatever, which they > will also understand, start talking about AffineTransforms and I think > we will scare people off). >> --------------------- >> >> My other main concern centers on map projections. The MEP currently >> mentions: >> >> an anticipated structure of a base mapping class with a >> coordinate system in lat/lon coordinates, but with different >> mapping projections available for the conversion between the Axes >> coordinate system and the screen. >> >> >> However, this is a bad approach for cartographic data. Geographic is >> not the base for a projected coordinate system. There are several >> reasons for that. >> >> 1. Map data is usually _in the projected coordinate system_. Lat, >> long data is actually not terribly common unless you're working with >> global datasets. >> 2. Raster data (i.e. anything displayed with imshow) is typically >> going to be gridded on a regular grid in the projected coordinate >> system. Forcing a transformation back to a non-uniform grid in lat, >> long space then back onto a different uniform grid than the original >> in display space is unnecessarily expensive. >> >> One of the great things about Cartopy is that it leaves the >> fundamental Cartesian projected space unchanged, and let's you >> specify the transform if you want to use geographic coordinates. >> Basemap handles it a bit differently but has the same core concept. >> Latitudes and longitudes aren't the data coordinate system. The >> projected coordinate system is. >> >> There's a reason for that approach. Forcing people to convert their >> data into a geographic coordinate system before plotting it is a bad >> idea. It's good to have plotting methods that allow geographic >> coordinates, but bad to require that transformation. (I'll skip the >> very important datum part for the moment. Just be aware that a lat, >> long only gets you to within ~1km of a location without more >> information.) > Hmm, when I have used Basemap, the data files I work with I always get > in lat/lon format. One of my biggest annoyances with Basemap comes > from having to work projection coordinates. I move the mouse over the > map and statusbar shows me useless projection coordinate information; > I want to rotate the globe (in 'ortho' projection), but I can't, it > becomes very difficult to use from a user interface point of view. > > I think the solution here comes from using a dual approach. With the > functions above I used the term base, as in the ``axes_to_base`` and > ``base_to_axes`` functions. Here ``base`` defines the projected > coordinates. We can then leave it up to the user to decide whether to > plot in axes coordinates or base coordinates. We can start of leaving > the axes side unimplemented, and perhaps we will never implement the > axes side for some Axes classes... what do you think? > > Best, > OceanWolf > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From elmar at net4werling.de Sun Sep 6 17:55:43 2015 From: elmar at net4werling.de (elmar werling) Date: Sun, 06 Sep 2015 17:55:43 +0200 Subject: [Matplotlib-devel] colorbar with date Message-ID: Hi all, try to make a colobar with date type data is causing a type error. Is there a solution? Any help is wellcome Elmar Python 3 np_version : 1.9.2 pd version : 0.16.2 mpl.version: 1.4.3 ########################### import numpy as np import pandas as pd import matplotlib.pyplot as plt N = 50 df = pd.DataFrame({ 'x': np.random.randn(N), 'y': np.random.randn(N), 'z': pd.date_range(start='2015-01-01', periods=N, freq='D')}) fig, ax = plt.subplots() smap = ax.scatter(df.x, df.y, s=50, c=df.z) cb = plt.colorbar(smap) plt.show() ########################### --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () 1 fig, ax = plt.subplots() 2 smap = ax.scatter(df2.x, df2.y, s=50, c=df2.z) ----> 3 cb = plt.colorbar(smap) /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/pyplot.py in colorbar(mappable, cax, ax, **kw) 2157 ax = gca() 2158 -> 2159 ret = gcf().colorbar(mappable, cax = cax, ax=ax, **kw) 2160 draw_if_interactive() 2161 return ret /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/figure.py in colorbar(self, mappable, cax, ax, use_gridspec, **kw) 1504 cax, kw = cbar.make_axes(ax, **kw) 1505 cax.hold(True) -> 1506 cb = cbar.colorbar_factory(cax, mappable, **kw) 1507 1508 self.sca(current_ax) /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py in colorbar_factory(cax, mappable, **kwargs) 1316 cb = ColorbarPatch(cax, mappable, **kwargs) 1317 else: -> 1318 cb = Colorbar(cax, mappable, **kwargs) 1319 1320 cid = mappable.callbacksSM.connect('changed', cb.on_mappable_changed) /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py in __init__(self, ax, mappable, **kw) 892 kw['alpha'] = mappable.get_alpha() 893 --> 894 ColorbarBase.__init__(self, ax, **kw) 895 896 def on_mappable_changed(self, mappable): /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py in __init__(self, ax, cmap, norm, alpha, values, boundaries, orientation, ticklocation, extend, spacing, ticks, format, drawedges, filled, extendfrac, extendrect, label) 319 # The rest is in a method so we can recalculate when clim changes. 320 self.config_axis() --> 321 self.draw_all() 322 323 def _extend_lower(self): /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py in draw_all(self) 340 and do all the drawing. 341 ''' --> 342 self._process_values() 343 self._find_range() 344 X, Y = self._mesh() /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py in _process_values(self, b) 660 self.norm.vmin, self.norm.vmax = mtrans.nonsingular(self.norm.vmin, 661 self.norm.vmax, --> 662 expander=0.1) 663 664 b = self.norm.inverse(self._uniform_y(self.cmap.N + 1)) /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/transforms.py in nonsingular(vmin, vmax, expander, tiny, increasing) 2681 returns -*expander*, *expander*. 2682 ''' -> 2683 if (not np.isfinite(vmin)) or (not np.isfinite(vmax)): 2684 return -expander, expander 2685 swapped = False TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe'' From joferkington at gmail.com Sun Sep 6 19:57:33 2015 From: joferkington at gmail.com (Joe Kington) Date: Sun, 6 Sep 2015 12:57:33 -0500 Subject: [Matplotlib-devel] MEP 29 Axes Refactor In-Reply-To: <55EB4C4B.6090902@yahoo.co.uk> References: <55EB0736.7090607@yahoo.co.uk> <55EB4C4B.6090902@yahoo.co.uk> Message-ID: My main concern is that this proposal would change the role of Axes. Currently, it's primarily a container. If I understand you correctly you don't like the idea of forcing Artists to > use the transform. > Actually, my key problem is having the Axes responsible for going between "data" coordinates and "screen"/"display" coordinates. Right now, the Axes is not at all responsible for that. If I'm understanding this proposal correctly, it would shift even more into Axes. As far as I see it, all coordinates supplied to an Artist will come in the > form of Axes coordinates, i.e. Axes space, and thus we need to transform > those coordinates to screen coordinates... > The problem here is that most Artists don't work in data coordinates. Only a very small number, such as those produced by user-focused plotting methods, are actually in data coordinates. Most of the artists that belong to the Axes actually don't have `ax.transData` as their transform. For example, consider the Axes patch, the ticks, tick labels, spines, titles and labels, etc. Even artists produced by user-facing functions often aren't in "data" space. Consider `annotate`, for example. > however on a spherical geometry, these "straight" lines do not conform to > the Euclid definition of straight, we need to draw them curved. Because of > this the transform will need to come very late in the drawing process. For what it's worth, that's exactly the type of thing that I don't think it makes sense to have the Axes responsible for. Right now, Transform handles this. Specifically the `tranform_path_non_affine` method. This allows these sort of transformations to happen at draw time. I think the solution here comes from using a dual approach. With the > functions above I used the term base, as in the ``axes_to_base`` and > ``base_to_axes`` functions. Here ``base`` defines the projected > coordinates. We can then leave it up to the user to decide whether to plot > in axes coordinates or base coordinates. We can start of leaving the axes > side unimplemented, and perhaps we will never implement the axes side for > some Axes classes... what do you think? > For what it's worth, that's what we currently have, in my opinion. Each artist has a Transform. Its only role is to convert points and paths (to handle non-euclidian geometries) from whatever the data for the artist is in to display coordinates. The Transform that the artist has defines what coordinates system that artist's data is in. This makes it easy to do things like: import matplotlib.pyplot as plt fig, ax = plt.subplots() ax.text(0.1, 0.9, 'This will stay in-place', transform=ax.transAxes) ax.plot(range(10), color='royalblue', lw=3) ax.set(title='Be sure to pan and zoom') plt.show() Cartopy is another fantastic example. Have a look at how Cartopy handles the difference between projected coordinates and geodetic coordinates: http://scitools.org.uk/cartopy/docs/latest/matplotlib/intro.html#adding-data-to-the-map Which transform you specify defines which coordinate system is being used for the data. The key here is that the Axes isn't doing the transformation at all. Making the Axes responsible for the transformation between "data" and "display" coordinates makes it much harder to implement things such as this. There are a lot of artists that are logically a part of the Axes but aren't in the "data" coordinate system. Hopefully that helps clarify my viewpoint, at any rate. Cheers! -Joe On Sat, Sep 5, 2015 at 3:10 PM, OceanWolf wrote: > > > > > Not too sure what you meant by ````. > > > > On 05/09/15 19:25, Joe Kington wrote: > > > First off, I don't intend this to come across as overly critical! I think > this is a very good discussion to have. > Also, I tend to have a bad "knee-jerk" reaction to change and tend to come > around over time, so keep that in mind too. :) > > No worries, I experience the same, and yes I wanted to open this up for > just this kind of interrogation, especially as we have a lot of axes > related code, and I have only touched a fraction of it to date. > > To explain where I come from, I should say that I like to work bottom-up. > I find designing good code starts with asking probing questions about what > you want to model, in this case we have an ``_AxesBase`` class and so by > definition it should model an abstract Axes, because of this in the > "Detailed Description" of this MEP I begin by asking the question probing > the definition of an Axes. I believe that if we model the world > intutitively as we see it, everything else will fall into place. I find > the most direct route in code usually contains lots of inflexibility, like > building a road through the mountain, you might go the direct route, but it > becomes very difficult to maintain and expand upon. Hence the focus lies > in the journey. > > > However, while I agree that `Axes` is quite a beast, I'm not sure this > proposal simplifies things. From my perspective, it adds complexity. If > I'm understanding correctly, this would effectively tie the Transform stack > to the Axes, instead of having the Axes generate a Transform object that > may or may not be used by the artists in the Axes. > > If I understand you correctly you don't like the idea of forcing Artists > to use the transform. I don't see this as a problem (at the moment). As > far as I see it, all coordinates supplied to an Artist will come in the > form of Axes coordinates, i.e. Axes space, and thus we need to transform > those coordinates to screen coordinates... at least at some point, probably > when it comes to drawing... I especially think of drawing a triangle onto a > spherical geometry, see https://en.wikipedia.org/wiki/Spherical_geometry. > We create a Polygon patch and supply the three vertices that define our > Triangle... however on a spherical geometry, these "straight" lines do not > conform to the Euclid definition of straight, we need to draw them curved. > Because of this the transform will need to come very late in the drawing > process. > > First we define our coordinate transformation functions: >> axes_to_base(self, *q) base_to_axes(self, x, y) >> >> The term base could get replaced with screen but for now we will keep it >> simple to reflect another transformation from base coords to screen coords, >> e.g. perhaps to differentiate between window and screen coords. >> > > This is my main concern. We have a (i.m.o.) very flexible and actually > quite clean Transform system to handle this. Why shift away from it? > `ax.transData` may be non-PEP8 naming, but it's a good way to do this. The > concept of having Transform objects that handle this but are separate from > the Axes gives a lot of flexibility. In my opinion, the core concept of > having this transformation handled by a Transform object that's separate > from the Axes is one of the best things about matplotlib's design. > > Or am I misunderstanding, and this is just a refactoring of > `_get_core_transform` and `_get_affine_transform` into one method? > > As far as I know, I want to keep the transform system. I think I do just > mean refactoring that into one method. I say think as I still don't feel > fully understand how it all works, the Transform system, brilliant, but > very mind-boggling. I had to delve into it to find a bug reported by a > user on github, and went through around 50 (perhaps more) Transform > operations before I got to the problem. If you need to debug part of it, > like i had to, it becomes a tangled mess, luckily for most people they > don't have to, and the usage works quite simply. When I tracked down the > bug I also spent quite some time trying to figure out the Transform > classes, prior to the bug I only knew of Rotation, Shear and Reflection > Transforms. Anyway my point here comes that while great, it can become > quite the head-ache for the average user developer, especially for those > who know even less then I do about transforms, and so I want to blackbox > the transforms in the Axes with simple names such as > axes_to_***_coords(self, *q), and ***_to_axes_coords(self, x, y). > > So I want to make it easy for people to write their own axes with their > own transform methods without having to worry about how the rest of the > Artist code and plot methods work (unless it works really bizarrely); and I > want people to work on Artist code, and creating their own tools and user > interaction stuff without having to worry about learning about transforms > (they just need to know that these two methods will do the conversion for > them from data coordinates, which they understand, to the location on the > screen or whatever, which they will also understand, start talking about > AffineTransforms and I think we will scare people off). > > --------------------- > > My other main concern centers on map projections. The MEP currently > mentions: > > an anticipated structure of a base mapping class with a coordinate system >> in lat/lon coordinates, but with different mapping projections available >> for the conversion between the Axes coordinate system and the screen. >> > > However, this is a bad approach for cartographic data. Geographic is not > the base for a projected coordinate system. There are several reasons for > that. > > 1. Map data is usually _in the projected coordinate system_. Lat, long > data is actually not terribly common unless you're working with global > datasets. > 2. Raster data (i.e. anything displayed with imshow) is typically going to > be gridded on a regular grid in the projected coordinate system. Forcing a > transformation back to a non-uniform grid in lat, long space then back onto > a different uniform grid than the original in display space is > unnecessarily expensive. > > One of the great things about Cartopy is that it leaves the fundamental > Cartesian projected space unchanged, and let's you specify the transform if > you want to use geographic coordinates. Basemap handles it a bit > differently but has the same core concept. Latitudes and longitudes aren't > the data coordinate system. The projected coordinate system is. > > There's a reason for that approach. Forcing people to convert their data > into a geographic coordinate system before plotting it is a bad idea. It's > good to have plotting methods that allow geographic coordinates, but bad to > require that transformation. (I'll skip the very important datum part for > the moment. Just be aware that a lat, long only gets you to within ~1km of > a location without more information.) > > Hmm, when I have used Basemap, the data files I work with I always get in > lat/lon format. One of my biggest annoyances with Basemap comes from > having to work projection coordinates. I move the mouse over the map and > statusbar shows me useless projection coordinate information; I want to > rotate the globe (in 'ortho' projection), but I can't, it becomes very > difficult to use from a user interface point of view. > > I think the solution here comes from using a dual approach. With the > functions above I used the term base, as in the ``axes_to_base`` and > ``base_to_axes`` functions. Here ``base`` defines the projected > coordinates. We can then leave it up to the user to decide whether to plot > in axes coordinates or base coordinates. We can start of leaving the axes > side unimplemented, and perhaps we will never implement the axes side for > some Axes classes... what do you think? > > Best, > OceanWolf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elmar at net4werling.de Mon Sep 7 21:36:10 2015 From: elmar at net4werling.de (elmar werling) Date: Mon, 07 Sep 2015 21:36:10 +0200 Subject: [Matplotlib-devel] colorbar with date In-Reply-To: References: Message-ID: <55EDE72A.4060403@net4werling.de> found a solution import numpy as np import pandas as pd import matplotlib.pyplot as plt from matplotlib.dates import DateFormatter, date2num N = 50 df = pd.DataFrame({ 'x': np.random.randn(N), 'y': np.random.randn(N), 'z': pd.date_range(start='2015-01-01', periods=N, freq='D')}) fig, ax = plt.subplots() smap = ax.scatter(df2.x, df2.y, s=50, c=[date2num(i.date()) for i in df2.z]) # <== cb = fig.colorbar(smap, orientation='vertical', shrink=0.9, format=DateFormatter('%d %b %y')) # <== plt.show() On 06.09.2015 17:55, elmar werling wrote: > Hi all, > > try to make a colobar with date type data is causing a type error. Is > there a solution? > > Any help is wellcome > Elmar > > > Python 3 > np_version : 1.9.2 > pd version : 0.16.2 > mpl.version: 1.4.3 > > ########################### > import numpy as np > import pandas as pd > import matplotlib.pyplot as plt > > N = 50 > df = pd.DataFrame({ > 'x': np.random.randn(N), > 'y': np.random.randn(N), > 'z': pd.date_range(start='2015-01-01', periods=N, freq='D')}) > > fig, ax = plt.subplots() > smap = ax.scatter(df.x, df.y, s=50, c=df.z) > cb = plt.colorbar(smap) > plt.show() > > ########################### > > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > in () > 1 fig, ax = plt.subplots() > 2 smap = ax.scatter(df2.x, df2.y, s=50, c=df2.z) > ----> 3 cb = plt.colorbar(smap) > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/pyplot.py > in colorbar(mappable, cax, ax, **kw) > 2157 ax = gca() > 2158 > -> 2159 ret = gcf().colorbar(mappable, cax = cax, ax=ax, **kw) > 2160 draw_if_interactive() > 2161 return ret > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/figure.py > in colorbar(self, mappable, cax, ax, use_gridspec, **kw) > 1504 cax, kw = cbar.make_axes(ax, **kw) > 1505 cax.hold(True) > -> 1506 cb = cbar.colorbar_factory(cax, mappable, **kw) > 1507 > 1508 self.sca(current_ax) > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py > in colorbar_factory(cax, mappable, **kwargs) > 1316 cb = ColorbarPatch(cax, mappable, **kwargs) > 1317 else: > -> 1318 cb = Colorbar(cax, mappable, **kwargs) > 1319 > 1320 cid = mappable.callbacksSM.connect('changed', > cb.on_mappable_changed) > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py > in __init__(self, ax, mappable, **kw) > 892 kw['alpha'] = mappable.get_alpha() > 893 > --> 894 ColorbarBase.__init__(self, ax, **kw) > 895 > 896 def on_mappable_changed(self, mappable): > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py > in __init__(self, ax, cmap, norm, alpha, values, boundaries, > orientation, ticklocation, extend, spacing, ticks, format, drawedges, > filled, extendfrac, extendrect, label) > 319 # The rest is in a method so we can recalculate when > clim changes. > 320 self.config_axis() > --> 321 self.draw_all() > 322 > 323 def _extend_lower(self): > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py > in draw_all(self) > 340 and do all the drawing. > 341 ''' > --> 342 self._process_values() > 343 self._find_range() > 344 X, Y = self._mesh() > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/colorbar.py > in _process_values(self, b) > 660 self.norm.vmin, self.norm.vmax = > mtrans.nonsingular(self.norm.vmin, > 661 self.norm.vmax, > --> 662 expander=0.1) > 663 > 664 b = self.norm.inverse(self._uniform_y(self.cmap.N + > 1)) > > /home/elmar/anaconda3/envs/py3/lib/python3.4/site-packages/matplotlib/transforms.py > in nonsingular(vmin, vmax, expander, tiny, increasing) > 2681 returns -*expander*, *expander*. > 2682 ''' > -> 2683 if (not np.isfinite(vmin)) or (not np.isfinite(vmax)): > 2684 return -expander, expander > 2685 swapped = False > > TypeError: ufunc 'isfinite' not supported for the input types, and the > inputs could not be safely coerced to any supported types according to > the casting rule ''safe'' From efiring at hawaii.edu Tue Sep 8 21:30:47 2015 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 8 Sep 2015 09:30:47 -1000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 Message-ID: <55EF3767.8070001@hawaii.edu> test: time python -c "from matplotlib import pyplot" On a linux VM with Py 3.4 the user time is around 0.25 s for 1.4.3 0.5 s for master That's quite a difference. Can anyone else reproduce this? Any ideas as to what is causing the slowdown? In both tests the backend was tkagg, so the difference was not a matter of importing different gui toolkits. Eric From tcaswell at gmail.com Tue Sep 8 21:51:43 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 08 Sep 2015 19:51:43 +0000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: <55EF3767.8070001@hawaii.edu> References: <55EF3767.8070001@hawaii.edu> Message-ID: My guess is that this has to do with disk access? With venvs running on a ramdisk I get almost identical times, particularly if I run it a couple of times: 15:39 $ time python -c "from matplotlib import pyplot; import matplotlib; print(matplotlib.__version__)" 1.4.3 real 0m0.377s user 0m0.343s sys 0m0.030s 15:36 $ time python -c "from matplotlib import pyplot; import matplotlib; print(matplotlib.__version__)" 1.5.dev1 real 0m0.362s user 0m0.327s sys 0m0.030s Both of those times fluctuate and despite what I pasted, 1.4.3 seems to be faster more often than not (but by hundredths of seconds). Running this command several times seems the later runs seem to be faster than the first time. Tom On Tue, Sep 8, 2015 at 3:30 PM Eric Firing wrote: > test: > > time python -c "from matplotlib import pyplot" > > On a linux VM with Py 3.4 the user time is around > > 0.25 s for 1.4.3 > 0.5 s for master > > That's quite a difference. Can anyone else reproduce this? Any ideas > as to what is causing the slowdown? > > In both tests the backend was tkagg, so the difference was not a matter > of importing different gui toolkits. > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue Sep 8 22:42:15 2015 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 8 Sep 2015 10:42:15 -1000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: References: <55EF3767.8070001@hawaii.edu> Message-ID: <55EF4827.4030404@hawaii.edu> On 2015/09/08 9:51 AM, Thomas Caswell wrote: > My guess is that this has to do with disk access? With venvs running on > a ramdisk I get almost identical times, particularly if I run it a > couple of times: > > 15:39$ time python -c "from matplotlib import pyplot; import matplotlib; > print(matplotlib.__version__)" > 1.4.3 > > real 0m0.377s > user 0m0.343s > sys 0m0.030s > > 15:36$ time python -c "from matplotlib import pyplot; import matplotlib; > print(matplotlib.__version__)" > 1.5.dev1 > > real 0m0.362s > user 0m0.327s > sys 0m0.030s > > Both of those times fluctuate and despite what I pasted, 1.4.3 seems to > be faster more often than not (but by hundredths of seconds). > > Running this command several times seems the later runs seem to be > faster than the first time. Running multiple times one does see variations, but not large ones compared to the factor of two I am getting between the versions. My environment is a virtualenv in a VMWare linux VM on a Mac, with the disk access via VMWare's hgfs. The Mac has SSD, so the physical disk access is quick; and at least some things will be retrieved from cache on multiple runs. The tests were made using the same VM and the same virtualenv, so the only thing that changed was whether I had just build mpl from 1.4.3 or from master. Now I have tried the experiment on the OSX side, and I get very similar results, except that all the times are a little bit longer than on the linux VM: (python3)efiring at manini2:~/work/programs/py/ladcp_netcdf$ time python -c "from matplotlib import pyplot; import matplotlib; print(matplotlib.__version__)" 1.4.3 real 0m0.379s user 0m0.321s sys 0m0.055s (testmpl3)efiring at manini2:~/work/programs/py/mpl/matplotlib$ time python -c "from matplotlib import pyplot; import matplotlib; print(matplotlib.__version__)" 1.5.dev1 real 0m0.795s user 0m0.704s sys 0m0.086s I guess the fact that the linux VM on OSX is faster than native OSX points to disk access in some form--maybe there is more caching on the linux side--but the puzzle remains: why the factor of two difference between 1.4.3 and master in these two reasonably normal configurations? Eric > > Tom > > On Tue, Sep 8, 2015 at 3:30 PM Eric Firing > wrote: > > test: > > time python -c "from matplotlib import pyplot" > > On a linux VM with Py 3.4 the user time is around > > 0.25 s for 1.4.3 > 0.5 s for master > > That's quite a difference. Can anyone else reproduce this? Any ideas > as to what is causing the slowdown? > > In both tests the backend was tkagg, so the difference was not a matter > of importing different gui toolkits. > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From njs at pobox.com Tue Sep 8 22:51:37 2015 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 8 Sep 2015 13:51:37 -0700 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: <55EF4827.4030404@hawaii.edu> References: <55EF3767.8070001@hawaii.edu> <55EF4827.4030404@hawaii.edu> Message-ID: "User" and "system" time are both measures of cpu time. Disk access shows up in the difference between real - (user + sys). (Also disk access time is never going to be measurable for a smallish read only workload like this after the first time you run it, because the OS will cache everything in RAM. If you want to measure disk access time then you need to drop caches before each test. In the VM case I guess you might need to do this on both the guest and host.) Anyway a 300 ms difference in cpu time is pretty blatant, I'd just run it under a profiler and see what pops up. -n On Sep 8, 2015 1:42 PM, "Eric Firing" wrote: > On 2015/09/08 9:51 AM, Thomas Caswell wrote: > >> My guess is that this has to do with disk access? With venvs running on >> a ramdisk I get almost identical times, particularly if I run it a >> couple of times: >> >> 15:39$ time python -c "from matplotlib import pyplot; import matplotlib; >> print(matplotlib.__version__)" >> 1.4.3 >> >> real 0m0.377s >> user 0m0.343s >> sys 0m0.030s >> >> 15:36$ time python -c "from matplotlib import pyplot; import matplotlib; >> print(matplotlib.__version__)" >> 1.5.dev1 >> >> real 0m0.362s >> user 0m0.327s >> sys 0m0.030s >> >> Both of those times fluctuate and despite what I pasted, 1.4.3 seems to >> be faster more often than not (but by hundredths of seconds). >> >> Running this command several times seems the later runs seem to be >> faster than the first time. >> > > Running multiple times one does see variations, but not large ones > compared to the factor of two I am getting between the versions. My > environment is a virtualenv in a VMWare linux VM on a Mac, with the disk > access via VMWare's hgfs. The Mac has SSD, so the physical disk access is > quick; and at least some things will be retrieved from cache on multiple > runs. The tests were made using the same VM and the same virtualenv, so the > only thing that changed was whether I had just build mpl from 1.4.3 or from > master. > > Now I have tried the experiment on the OSX side, and I get very similar > results, except that all the times are a little bit longer than on the > linux VM: > > > (python3)efiring at manini2:~/work/programs/py/ladcp_netcdf$ time python -c > "from matplotlib import pyplot; import matplotlib; > print(matplotlib.__version__)" > 1.4.3 > > real 0m0.379s > user 0m0.321s > sys 0m0.055s > > (testmpl3)efiring at manini2:~/work/programs/py/mpl/matplotlib$ time python > -c "from matplotlib import pyplot; import matplotlib; > print(matplotlib.__version__)" > 1.5.dev1 > > real 0m0.795s > user 0m0.704s > sys 0m0.086s > > I guess the fact that the linux VM on OSX is faster than native OSX points > to disk access in some form--maybe there is more caching on the linux > side--but the puzzle remains: why the factor of two difference between > 1.4.3 and master in these two reasonably normal configurations? > > Eric > > > >> Tom >> >> On Tue, Sep 8, 2015 at 3:30 PM Eric Firing > > wrote: >> >> test: >> >> time python -c "from matplotlib import pyplot" >> >> On a linux VM with Py 3.4 the user time is around >> >> 0.25 s for 1.4.3 >> 0.5 s for master >> >> That's quite a difference. Can anyone else reproduce this? Any ideas >> as to what is causing the slowdown? >> >> In both tests the backend was tkagg, so the difference was not a >> matter >> of importing different gui toolkits. >> >> Eric >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue Sep 8 22:53:07 2015 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 8 Sep 2015 10:53:07 -1000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: References: <55EF3767.8070001@hawaii.edu> Message-ID: <55EF4AB3.6040001@hawaii.edu> On 2015/09/08 9:51 AM, Thomas Caswell wrote: > My guess is that this has to do with disk access? With venvs running on > a ramdisk I get almost identical times, particularly if I run it a > couple of times: I ran strace python -c "from matplotlib import pyplot" > ../tests/master.trace 2>&1 and similar for v1.4.3: -rw-r--r-- 1 efiring efiring 448374 Sep 8 10:46 v143.trace -rw-r--r-- 1 efiring efiring 774942 Sep 8 10:49 master.trace (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep matplotlib master.trace | wc 899 4988 127344 (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep matplotlib v143.trace | wc 693 3890 99963 (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep stat master.trace | wc 4307 27785 463042 (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep stat v143.trace | wc 2381 14898 248260 Somehow, master seems to have nearly doubled the number of stat calls. Maybe there is more circularity in the imports now? Eric From njs at pobox.com Tue Sep 8 23:01:10 2015 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 8 Sep 2015 14:01:10 -0700 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: <55EF4AB3.6040001@hawaii.edu> References: <55EF3767.8070001@hawaii.edu> <55EF4AB3.6040001@hawaii.edu> Message-ID: On Sep 8, 2015 1:53 PM, "Eric Firing" wrote: > > On 2015/09/08 9:51 AM, Thomas Caswell wrote: >> >> My guess is that this has to do with disk access? With venvs running on >> a ramdisk I get almost identical times, particularly if I run it a >> couple of times: > > > I ran > > strace python -c "from matplotlib import pyplot" > ../tests/master.trace 2>&1 > and similar for v1.4.3: > > -rw-r--r-- 1 efiring efiring 448374 Sep 8 10:46 v143.trace > -rw-r--r-- 1 efiring efiring 774942 Sep 8 10:49 master.trace > (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep matplotlib master.trace | wc > 899 4988 127344 > (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep matplotlib v143.trace | wc > 693 3890 99963 > (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep stat master.trace | wc > 4307 27785 463042 > (python3)efiring at manini4:~/work/programs/py/mpl/tests$ grep stat v143.trace | wc > 2381 14898 248260 > > Somehow, master seems to have nearly doubled the number of stat calls. Maybe there is more circularity in the imports now? Do you have the same number of entries on sys.path for the two interpreters? Most stat calls at import are checking to see which directory in sys.path has the requested items. Do you have any reason to believe that stat calls are actually what's taking time? The calls themselves should show up in system time, which is not very different in your quoted numbers -- though there could be some python level overhead for processing each stat call depending on what you're doing (which would show up in user time). You can also use the -T options to strace to record timing information (though of course it also slows things down). But generally strace is not a great tool for investigating user cpu time differences, because it only watches user<->system transitions. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Sep 9 02:22:06 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 00:22:06 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed In-Reply-To: References: Message-ID: Andres, Have you made any progress on this? Using the code in integral_demo.py ```python import numpy as np import matplotlib.pyplot as plt from matplotlib.patches import Polygon def func(x): return (x - 3) * (x - 5) * (x - 7) + 85 a, b = 2, 9 # integral limits # Make the shaded region ix = np.linspace(a, b) iy = func(ix) verts = [(a, 0)] + list(zip(ix, iy)) + [(b, 0)] poly = Polygon(verts, facecolor='0.9', edgecolor='0.5') pth = poly.get_path() ``` which if you look at the vertices and codes on both 1.4.3 and current(ish) master you get ``` In [73]: pth.vertices Out[74]: array([[ 2. , 0. ], [ 2. , 70. ], [ 2.14285714, 73.10495627], [ 2.28571429, 75.86005831], [ 2.42857143, 78.28279883], [ 2.57142857, 80.39067055], [ 2.71428571, 82.20116618], [ 2.85714286, 83.73177843], [ 3. , 85. ], [ 3.14285714, 86.02332362], [ 3.28571429, 86.81924198], [ 3.42857143, 87.40524781], [ 3.57142857, 87.79883382], [ 3.71428571, 88.01749271], [ 3.85714286, 88.0787172 ], [ 4. , 88. ], [ 4.14285714, 87.79883382], [ 4.28571429, 87.49271137], [ 4.42857143, 87.09912536], [ 4.57142857, 86.63556851], [ 4.71428571, 86.11953353], [ 4.85714286, 85.56851312], [ 5. , 85. ], [ 5.14285714, 84.43148688], [ 5.28571429, 83.88046647], [ 5.42857143, 83.36443149], [ 5.57142857, 82.90087464], [ 5.71428571, 82.50728863], [ 5.85714286, 82.20116618], [ 6. , 82. ], [ 6.14285714, 81.9212828 ], [ 6.28571429, 81.98250729], [ 6.42857143, 82.20116618], [ 6.57142857, 82.59475219], [ 6.71428571, 83.18075802], [ 6.85714286, 83.97667638], [ 7. , 85. ], [ 7.14285714, 86.26822157], [ 7.28571429, 87.79883382], [ 7.42857143, 89.60932945], [ 7.57142857, 91.71720117], [ 7.71428571, 94.13994169], [ 7.85714286, 96.89504373], [ 8. , 100. ], [ 8.14285714, 103.47230321], [ 8.28571429, 107.32944606], [ 8.42857143, 111.58892128], [ 8.57142857, 116.26822157], [ 8.71428571, 121.38483965], [ 8.85714286, 126.95626822], [ 9. , 133. ], [ 9. , 0. ], [ 2. , 0. ]]) In [75]: pth.codes Out[75]: array([ 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 79], dtype=uint8) ``` which is is both cases closed due to the `closed` kwarg on the `Polygon` `__init__`, if you change this to `False` you get back open paths. The backend API has not changed between 1.4.3 and current master, you should be able to develop a backend which will work with both. If you have found API breaks we would really like to know about them! Tom On Fri, Aug 14, 2015 at 11:26 AM Jens Nielsen wrote: > I can reproduce the problem with the GTK backend but not the GTKAgg or > GTKCairo backends. Unless you have some specific reason for using the GTK > backend I would strongly recommend against it. It is untested, > unmaintained and officially discouraged: > http://matplotlib.org/faq/usage_faq.html#what-is-a-backend I would > recommend you to use GTKAgg instead. > > Furthermore the GDK toolkit, used in that backend, has been dropped from > GTK3 which officially uses Cairo internally and thus Matplotlib only > supports GTK3Agg and GTK3Cario > > I guess the issue is likely a result of the large C++ refactoring in > master. > > best > Jens > > > > > fre. 14. aug. 2015 kl. 15.21 skrev Thomas Caswell : > >> Please keep all discussion on the mailing list ( >> matplotlib-devel at python.org). >> >> Being pedantic about versions, current master is v1.5.0dev1 , not 1.5.1 >> (which will be the first bug fix release in the 1.5 series which may or may >> not ever happen). >> >> I don't have gtk installed to easily test this and it looks fine with >> qt4agg, can you provide a minimal script and the code paths from a simple >> polygon? >> >> Tom >> >> On Fri, Aug 14, 2015 at 9:05 AM Andr?s Vargas wrote: >> >>> Hello Tom, >>> >>> Thanks for your prompt reply. I am using the function path.to_polygons() >>> and that gives me a non-closed path in matplotlib 1.4.3 (last stable >>> release) and give me a closed path in 1.5.1 (master from github). You can >>> see the problem if you run integral_demo.py with matplotlib 1.5.1 master >>> with matplotlib.use('gtk'). >>> >>> Thanks, Andres >>> >> >>> On Fri, Aug 14, 2015 at 8:13 AM, Thomas Caswell >>> wrote: >>> >>>> Did you mean 1.4.1 instead of 1.5.1 ? >>>> >>>> Exactly which paths are you looking at and how are you generating then >>>> on the mpl side? We have many ways to generate the paths and there maybe >>>> inconsistence in how closed paths are handled. >>>> >>>> Tom >>>> >>>> On Wed, Aug 12, 2015, 1:57 PM Andr?s Vargas wrote: >>>> >>>>> Hello, >>>>> >>>>> My name is Andres I am developing a backend for kivy. I was initially >>>>> developing for 1.5.1 and I found that the paths are coming with the initial >>>>> vertex at the end of the list. Does anyone know whether this is change in >>>>> the way paths are sent ? and how can be fixed coming from 1.4.3 since I am >>>>> developing the backend for that version. >>>>> >>>>> Thanks, Andres >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Matplotlib-devel mailing list >>>>> Matplotlib-devel at lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> >>>> >>> >>> >>> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Sep 9 02:23:17 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 00:23:17 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] IMPORTANT: Mailing lists are moving In-Reply-To: References: <55BBAB39.2080104@stsci.edu> Message-ID: As an update, nabble has now been updated as well (thanks to Hugo Teixeira). Tom On Tue, Aug 18, 2015 at 11:35 AM Thomas Caswell wrote: > I have corrected the landing page for the mailing list sign up (should be > live, might need to clear some caches). > > nabble is still a problem, maybe we should redirect that to gmane which > has been updated to look at the new address? > > Tom > > On Tue, Aug 18, 2015 at 11:17 AM Nicolas P. Rougier < > Nicolas.Rougier at inria.fr> wrote: > >> >> The mailing list pointer on the first page on matplotlib.org stil point >> to old mailing lists. >> >> See: Check the faq, the api docs, mailing list archives, and join the >> matplotlib mailing lists. Check out the matplotlib questions on >> stackoverflow. The search tool searches all of the documentation, including >> full text search of over 350 complete examples which exercise almost every >> corner of matplotlib. >> >> >> Nicolas >> >> >> > On 31 Jul 2015, at 19:07, Michael Droettboom wrote: >> > >> > Due to recent technical problems and changes in policy on SourceForge, >> we have decided to move the matplotlib mailing lists to python.org. >> > >> > To subscribe to the new mailing lists, please visit: >> > >> > ? For user questions and support: >> > https://mail.python.org/mailman/listinfo/matplotlib-users >> > matplotlib-users at python.org >> > ? For low-volume announcements about matplotlib releases and >> related events and software: >> > https://mail.python.org/mailman/listinfo/matplotlib-announce >> > matplotlib-announce at python.org >> > ? For developer discussion: >> > https://mail.python.org/mailman/listinfo/matplotlib-devel >> > matplotlib-devel at python.org >> > The old list will remain active in the meantime, but all new posts will >> auto-reply with the location of the new mailing lists. >> > >> > The old mailing list archives will remain available. >> > >> > Thanks to Ralf Hildebrandt at python.org for making this possible. >> > >> > Cheers, >> > Michael Droettboom >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Matplotlib-devel mailing list >> > Matplotlib-devel at lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Sep 9 02:44:59 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 00:44:59 +0000 Subject: [Matplotlib-devel] [Matplotlib-users] [matplotlib-devel] pyplot functions: do you rely on the "hold" kwarg? In-Reply-To: <5574C313.3090609@hawaii.edu> References: <5574B9A5.7060209@hawaii.edu> <5574C313.3090609@hawaii.edu> Message-ID: Following up on this one more time, is there anyone who uses `hold` as an integral part of your workflow? We would like to remove this feature from the library entirely and are trying to judge how fast we can do this. Tom On Sun, Jun 7, 2015 at 6:18 PM Eric Firing wrote: > On 2015/06/07 12:05 PM, Nathaniel Smith wrote: > > On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing wrote: > >> Matplotlib's pyplot retains quite a few vestiges from its original > >> Matlab-workalike heritage; we would like to gradually eliminate those > >> that no longer make sense. One such candidate is the "hold" kwarg that > >> every pyplot function has, with a "True" default. I don't think it > >> serves any useful purpose now, and getting rid of it would allow > >> considerable simplification to the code and, to a lesser extent, the > >> documentation. The default behavior would not change, only the ability > >> to change that behavior via either the rcParams['axes.hold'] parameter > >> or the "hold" kwarg in a pyplot function call. > >> > >> If you routinely use 'hold=False' and believe that removing it would be > >> a mistake, please let us know. > > > > I do actually use it with some regularity interactively, though I'm > > not particularly attached to it. Is there some equivalent though, like > > plt.whatever(..., hold=False) > > can become > > plt.clear(); plt.whatever(...) > > It's exactly equivalent to: > plt.cla(); plt.whatever(...) > > > ? The semantics would be that the current figure remains the current > > figure, but is reset so that the next operation starts from scratch. I > > notice that plt.clear() does not exist, but maybe it has another > > spelling :-). > > There are two types of "clear": > plt.clf() # clear the current Figure > plt.cla() # clear the current Axes > > Eric > > > > > (Basically the use case here is getting something like the > > edit-and-rerun-a-cell workflow, but when using a classic interactive > > REPL rather than the ipython notebook -- so I have a specific plot > > window up on my screen at a size and place where I can see it, and > > maybe some other plots in other windows in the background somewhere, > > and I want to quickly display different things into that window.) > > > > -n > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Sep 9 02:49:43 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 00:49:43 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] Fwd: python data vis Slack channels? In-Reply-To: References: <1B074089-5E96-4F07-8191-AFAFDDAC5D4F@continuum.io> <9A5FA3BB-5B9D-4B6E-9A0F-6825DD5367A6@continuum.io> Message-ID: Did anything come of this? Tom On Thu, May 7, 2015 at 12:39 PM Nathan Goldbaum wrote: > For what it's worth, there are matplotlib, scipy, and IPython channels on > the freenode IRC network. I often answer questions there. > > On Monday, May 4, 2015, Bryan Van de Ven wrote: > >> We've thought about gitter as well, personally my (slight) preference for >> Slack is that it does not require a GH account, and also, there is a nice >> OSS heroku app that provides a really nice "self-invite" button that shows >> how many users are on, too. You can see it on our test docs deploy: >> >> http://bokeh.pydata.org/en/test/index.html >> >> That said it is probably six of one, half dozen of the other. I'm not >> categorically opposed to looking into gitter some more. >> >> My hope (and intent) is really to have this as a place for users to >> congregate and self-support. We do intend to monitor, to the extent we can, >> but like you there is precious little bandwidth form core devs. >> >> Bryan >> >> >> > On May 4, 2015, at 11:45 AM, Thomas Caswell wrote: >> > >> > That sounds reasonable to me. My only concern is getting enough (any?) >> bandwidth from enough of the core mpl developers. >> > >> > IPython and scikit image both have gitter rooms running that seem to >> working well for them as well, is there any reason to go with slack over >> gitter? >> > >> > Tom >> > >> > ---------- Forwarded message --------- >> > From: Bryan Van de Ven >> > Date: Mon, May 4, 2015 at 11:44 AM >> > Subject: python data vis Slack channels? >> > To: Michael Droettboom , >> > >> > >> > Hi guys, >> > >> > We have been experimenting/toying with the idea of using a free Slack >> channel to provide a place for casual Bokeh user interactions. It occurred >> that it might be nice to have a single "pyvis.slack.com", that has >> channels for several OSS python vis libraries in one place. Would you have >> any interest in a #matplotlib channel there? If there is a better place to >> submit this proposal, please let me know. >> > >> > Regards, >> > >> > Bryan Van de Ven >> > >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Sep 9 03:05:09 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 01:05:09 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] pyplot-OO convergence In-Reply-To: References: <54274AD8.3000302@hawaii.edu> <54284AC2.6080208@hawaii.edu> Message-ID: As a follow up to this following things are in master/in the works: - auto-redraw on OO mutation is merged and will be in 1.5 - There is a draft implementation of using traitlets to capture artist properties in the works. Still many details that need to be worked out there, but there is a plausible path and we have the support of the IPython folks in this. In addition to cleaning up the API this will also provide use with an easy path to figure serialization. - some of the introspection issues can be addressed in python 3.3+ with Signature. That is something I plan to push on going forward Tom On Mon, Sep 29, 2014 at 7:34 AM Todd wrote: > > On Sun, Sep 28, 2014 at 7:52 PM, Eric Firing wrote: > >> Regarding Matlab: it is justly popular for many reasons. It is >> relatively easy to learn both by design and because of its consistent >> high-quality documentation. Matplotlib's success has resulted in large >> measure from its pyplot layer, which can shield learners and users from >> mpl's complexity, which allows learners to build on their Matlab >> knowledge, and which is particularly well suited to quick interactive >> data exploration. The problem with the Matlab/pyplot approach is that >> it doesn't scale well, so we see a chorus of advice along the lines of >> "don't use pyplot except for subplots() and show(); use the nice, >> explicit OO interface for everything else". But at present, this >> doesn't work well, because the OO approach is not interactive enough, >> and using the getters and setters is clumsy when typing at the >> console--in demonstrating, teaching, learning, and exploring >> interactively, every keystroke counts! >> >> > Matlab is actually slowly trying to transition to an OO-style interface of > their own. It has taken a LONG time, though. > > ------------------------------------------------------------------------------ > Slashdot TV. Videos for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Wed Sep 9 03:16:40 2015 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 8 Sep 2015 15:16:40 -1000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: References: <55EF3767.8070001@hawaii.edu> Message-ID: <55EF8878.6090303@hawaii.edu> On 2015/09/08 9:51 AM, Thomas Caswell wrote: > My guess is that this has to do with disk access? Nope. It's that master is pulling in ipython, if it can be found, even when the backend is selected as agg at the start. This is via install_repl_displayhook in pyplot.py. There might be other factors, but this is the big one. I will turn this into a github issue. Eric From tcaswell at gmail.com Wed Sep 9 03:48:24 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 09 Sep 2015 01:48:24 +0000 Subject: [Matplotlib-devel] import time doubled by master vs 1.4.3 In-Reply-To: <55EF8878.6090303@hawaii.edu> References: <55EF3767.8070001@hawaii.edu> <55EF8878.6090303@hawaii.edu> Message-ID: That would explain why I was not seeing it, I was testing in bare-bones venvs that did not have IPython installed. I have a PR in to fix it. On Tue, Sep 8, 2015 at 9:16 PM Eric Firing wrote: > On 2015/09/08 9:51 AM, Thomas Caswell wrote: > > My guess is that this has to do with disk access? > > Nope. It's that master is pulling in ipython, if it can be found, even > when the backend is selected as agg at the start. This is via > install_repl_displayhook in pyplot.py. > > There might be other factors, but this is the big one. I will turn this > into a github issue. > > Eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Thu Sep 10 15:03:54 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Thu, 10 Sep 2015 15:03:54 +0200 Subject: [Matplotlib-devel] MEP Process Message-ID: <55F17FBA.5070005@yahoo.co.uk> Hi Matplotlibers, Now that we have moved over to MEPs as pull requests (which I love), we now need to decide how to "track" these PRs. As far as I see it, we have two options. 1. Keep the wiki, but use it as a stub to track the PR(s). 2. Create a script for Travis that auto-numbers MEPs (and renames the filename of the MEP accordingly?) once an MEP has been merged into master. What do people think? Best, OceanWolf From njs at pobox.com Fri Sep 11 01:18:45 2015 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 10 Sep 2015 16:18:45 -0700 Subject: [Matplotlib-devel] MEP Process In-Reply-To: <55F17FBA.5070005@yahoo.co.uk> References: <55F17FBA.5070005@yahoo.co.uk> Message-ID: I believe that what Python does for PEPs is just, when the first draft is written you assign the number, and if it ends up being rejected or whatever, then oh well, now that's the number for a rejected PEP. They just have to be unique, it doesn't matter whether they're strictly in order by acceptance date or anything like that. On Thu, Sep 10, 2015 at 6:03 AM, OceanWolf wrote: > Hi Matplotlibers, > Now that we have moved over to MEPs as pull requests (which I love), we now > need to decide how to "track" these PRs. > > As far as I see it, we have two options. > 1. Keep the wiki, but use it as a stub to track the PR(s). > 2. Create a script for Travis that auto-numbers MEPs (and renames the > filename of the MEP accordingly?) once an MEP has been merged into master. > > What do people think? > > Best, > OceanWolf > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -- Nathaniel J. Smith -- http://vorpus.org From juichenieder-nabb at yahoo.co.uk Fri Sep 11 01:58:48 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 11 Sep 2015 01:58:48 +0200 Subject: [Matplotlib-devel] MEP Process In-Reply-To: References: <55F17FBA.5070005@yahoo.co.uk> Message-ID: <55F21938.3040706@yahoo.co.uk> Okay, that suggests the option 1 approach, as that way we can easily see which numbers we have already allocated, and allows us to easily keep track of MEP numbers while they still exist only in PR form. I just want to avoid numbering clashes later. If we agree on this, I can go through the wiki and get rid of the MEP specific pages there, replacing them with a list there, something like: MEP xx *Discussion*: MEP xx *Progress* On 11/09/15 01:18, Nathaniel Smith wrote: > I believe that what Python does for PEPs is just, when the first draft > is written you assign the number, and if it ends up being rejected or > whatever, then oh well, now that's the number for a rejected PEP. They > just have to be unique, it doesn't matter whether they're strictly in > order by acceptance date or anything like that. > > On Thu, Sep 10, 2015 at 6:03 AM, OceanWolf > wrote: >> Hi Matplotlibers, >> Now that we have moved over to MEPs as pull requests (which I love), we now >> need to decide how to "track" these PRs. >> >> As far as I see it, we have two options. >> 1. Keep the wiki, but use it as a stub to track the PR(s). >> 2. Create a script for Travis that auto-numbers MEPs (and renames the >> filename of the MEP accordingly?) once an MEP has been merged into master. >> >> What do people think? >> >> Best, >> OceanWolf >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > From schut at sarvision.nl Fri Sep 11 12:22:29 2015 From: schut at sarvision.nl (Vincent Schut) Date: Fri, 11 Sep 2015 12:22:29 +0200 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy Message-ID: Hi, I'm used to working with unstable versions for most of my numpy/scipy/etc stack (usually from git head). So I have installed numpy 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted matplotlib from git, but when I build this ("python setup.py build", or even with "python setup.py develop --no-deps"), it keeps building it's own numpy 1.9.2 egg, look at this snippet of the output: ... Installed /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg /usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: Module numpy was already imported from /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being added to sys.path ... Strange thing is, in the beginning matplotlib seems to happily recognize my numpy: REQUIRED DEPENDENCIES AND EXTENSIONS numpy: yes [version 1.11.0.dev0+3397fce] dateutil: yes [using dateutil version 2.4.2] pytz: yes [using pytz version 2015.4] cycler: yes [using cycler version 0.9.0] tornado: yes [using tornado version 4.2.1] pyparsing: yes [using pyparsing version 2.0.3] libagg: yes [Requires patches that have not been merged upstream. Using local copy.] freetype: yes [version 2.6.0] png: yes [version 1.6.18] qhull: yes [pkg-config information for 'qhull' could not be found. Using local copy.] However, it immediately starts building numpy 1.9.2 after that. Having more than one version of numpy (or whatever python package) just messes up my system, I don't want several different versions of numpy to co-exist. Anything I can do to make matplotlib recognize and use my numpy from git? Best, Vincent. From njs at pobox.com Fri Sep 11 12:40:02 2015 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 11 Sep 2015 03:40:02 -0700 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: Did you use pip to install those in-development versions of numpy etc., or just 'setup.py install'? The latter is unfortunately broken in several ways -- what might be biting you here is that it does not install the package metadata (.egg-info or .dist-info) that setuptools and pip need to know whether numpy is installed or not, what version it is, etc. -- this is separate from just having a numpy directory on your pythonpath. (Another thing that will bite you in the future is that when you use distutils/setup.py to install a package, then it's impossible to correctly uninstall or upgrade that package later, because it doesn't make a record of what files were installed.) The best / only correct way to install a package from source or a git checkout is 'pip install '; never run setup.py directly. (Yes, this is absurd, but I don't make the rules...) -n On Sep 11, 2015 03:30, "Vincent Schut" wrote: > Hi, > > I'm used to working with unstable versions for most of my numpy/scipy/etc > stack (usually from git head). So I have installed numpy > 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted > matplotlib from git, but when I build this ("python setup.py build", or > even with "python setup.py develop --no-deps"), it keeps building it's own > numpy 1.9.2 egg, look at this snippet of the output: > > ... > Installed > /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg > /usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: > Module numpy was already imported from > /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but > /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being > added to sys.path > ... > > Strange thing is, in the beginning matplotlib seems to happily recognize > my numpy: > > REQUIRED DEPENDENCIES AND EXTENSIONS > numpy: yes [version 1.11.0.dev0+3397fce] > dateutil: yes [using dateutil version 2.4.2] > pytz: yes [using pytz version 2015.4] > cycler: yes [using cycler version 0.9.0] > tornado: yes [using tornado version 4.2.1] > pyparsing: yes [using pyparsing version 2.0.3] > libagg: yes [Requires patches that have not been merged > upstream. Using local copy.] > freetype: yes [version 2.6.0] > png: yes [version 1.6.18] > qhull: yes [pkg-config information for 'qhull' could not > be > found. Using local copy.] > > However, it immediately starts building numpy 1.9.2 after that. > > Having more than one version of numpy (or whatever python package) just > messes up my system, I don't want several different versions of numpy to > co-exist. Anything I can do to make matplotlib recognize and use my numpy > from git? > > Best, > Vincent. > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Fri Sep 11 18:12:26 2015 From: chris.barker at noaa.gov (Chris Barker) Date: Fri, 11 Sep 2015 09:12:26 -0700 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith wrote: > Did you use pip to install those in-development versions of numpy etc., or > just 'setup.py install'? The latter is unfortunately broken in several ways > -- what might be biting you here is that it does not install the package > metadata (.egg-info or .dist-info) that setuptools and pip need to know > whether numpy is installed or not, what version it is, etc. -- this is > separate from just having a numpy directory on your pythonpath. > weird that setup.py develop --nodeps doesn't work, though. > The best / only correct way to install a package from source or a git > checkout is 'pip install '; never run setup.py directly. > > (Yes, this is absurd, but I don't make the rules...) > > Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a big hairy mess. But we *could* force, or at least encourage, the use of setuptools in the numpy build. The reason pip works is because it Monkey-patches setuptools into the install process. Or maybe I'm am mis-informed - this is very tangled up! -CHB > -n > On Sep 11, 2015 03:30, "Vincent Schut" wrote: > >> Hi, >> >> I'm used to working with unstable versions for most of my numpy/scipy/etc >> stack (usually from git head). So I have installed numpy >> 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted >> matplotlib from git, but when I build this ("python setup.py build", or >> even with "python setup.py develop --no-deps"), it keeps building it's own >> numpy 1.9.2 egg, look at this snippet of the output: >> >> ... >> Installed >> /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg >> /usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: >> Module numpy was already imported from >> /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but >> /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being >> added to sys.path >> ... >> >> Strange thing is, in the beginning matplotlib seems to happily recognize >> my numpy: >> >> REQUIRED DEPENDENCIES AND EXTENSIONS >> numpy: yes [version 1.11.0.dev0+3397fce] >> dateutil: yes [using dateutil version 2.4.2] >> pytz: yes [using pytz version 2015.4] >> cycler: yes [using cycler version 0.9.0] >> tornado: yes [using tornado version 4.2.1] >> pyparsing: yes [using pyparsing version 2.0.3] >> libagg: yes [Requires patches that have not been merged >> upstream. Using local copy.] >> freetype: yes [version 2.6.0] >> png: yes [version 1.6.18] >> qhull: yes [pkg-config information for 'qhull' could not >> be >> found. Using local copy.] >> >> However, it immediately starts building numpy 1.9.2 after that. >> >> Having more than one version of numpy (or whatever python package) just >> messes up my system, I don't want several different versions of numpy to >> co-exist. Anything I can do to make matplotlib recognize and use my numpy >> from git? >> >> Best, >> Vincent. >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Fri Sep 11 19:09:47 2015 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 11 Sep 2015 10:09:47 -0700 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: On Sep 11, 2015 9:13 AM, "Chris Barker" wrote: > > On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith wrote: [...] >> >> The best / only correct way to install a package from source or a git checkout is 'pip install '; never run setup.py directly. >> >> (Yes, this is absurd, but I don't make the rules...) > > Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a big hairy mess. > > But we *could* force, or at least encourage, the use of setuptools in the numpy build. The reason pip works is because it Monkey-patches setuptools into the install process. > > Or maybe I'm am mis-informed - this is very tangled up! pip monkeypatches setuptools into the install process... but first it monkeypatches setuptools to fix various weird behaviors. If you just use setuptools directly then you don't get the same thing as pip install. Off the top of my head: setuptools will try to easy_install any dependencies, and setuptools will default to installing into a weird directory with a .pth file. I'm not sure that it records what files were installed either. OTOH does at least install .egg-info so that other tools can tell that your package is installed later. It is a mess. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmhobson at gmail.com Fri Sep 11 19:44:44 2015 From: pmhobson at gmail.com (Paul Hobson) Date: Fri, 11 Sep 2015 10:44:44 -0700 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: On Fri, Sep 11, 2015 at 10:09 AM, Nathaniel Smith wrote: > On Sep 11, 2015 9:13 AM, "Chris Barker" wrote: > > > > On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith wrote: > [...] > >> > >> The best / only correct way to install a package from source or a git > checkout is 'pip install '; never run setup.py directly. > >> > >> (Yes, this is absurd, but I don't make the rules...) > > > > Yeah, the separation of concerns of distutils, setuptools, pipi, etc is > a big hairy mess. > > > > But we *could* force, or at least encourage, the use of setuptools in > the numpy build. The reason pip works is because it Monkey-patches > setuptools into the install process. > > > > Or maybe I'm am mis-informed - this is very tangled up! > > pip monkeypatches setuptools into the install process... but first it > monkeypatches setuptools to fix various weird behaviors. If you just use > setuptools directly then you don't get the same thing as pip install. > > Off the top of my head: setuptools will try to easy_install any > dependencies, and setuptools will default to installing into a weird > directory with a .pth file. I'm not sure that it records what files were > installed either. OTOH does at least install .egg-info so that other tools > can tell that your package is installed later. > > It is a mess. > > -n > While we're piling on, I think (it's hard to know) that I ran into an issue where pip was (thankfully) installing a local package with zip_safe=False, but setup.py was only install the egg, making accessing the package's bundled data very difficult. So yeah, +1 for "pip install " -------------- next part -------------- An HTML attachment was scrubbed... URL: From andnovar at gmail.com Wed Sep 9 11:00:00 2015 From: andnovar at gmail.com (=?UTF-8?Q?Andr=C3=A9s_Vargas?=) Date: Wed, 9 Sep 2015 05:00:00 -0400 Subject: [Matplotlib-devel] [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed In-Reply-To: References: Message-ID: Thomas, The problem is not in the Polygon class, rather it is in the method convert_path_to_polygons from _path.h in matplotlib 1.5dev1 and _path.cpp in matplotlib 1.4.3 . I print the polygons result from converting the path to polygon in the files attached. The polygons from this figure -> https://andnovar.files.wordpress.com/2015/08/screenshot-from-2015-08-03-175714.png There is something definitely not right from what you can see in the files. What I did temporary is that when is version >= 1.5 it will not consider the last two vertices which seems repeated in most of the cases. I got another question as well, I am getting troubles with the onHilite event (https://github.com/kivy-garden/garden.matplotlib/issues/19). I think it is related to the TimerBase. Can anyone tell me a little bit more about the TimerBase. Thanks, Andres On Tue, Sep 8, 2015 at 8:22 PM, Thomas Caswell wrote: > Andres, > > Have you made any progress on this? > > Using the code in integral_demo.py > > ```python > > import numpy as np > import matplotlib.pyplot as plt > from matplotlib.patches import Polygon > > > def func(x): > return (x - 3) * (x - 5) * (x - 7) + 85 > > > a, b = 2, 9 # integral limits > > # Make the shaded region > ix = np.linspace(a, b) > iy = func(ix) > verts = [(a, 0)] + list(zip(ix, iy)) + [(b, 0)] > poly = Polygon(verts, facecolor='0.9', edgecolor='0.5') > pth = poly.get_path() > ``` > > which if you look at the vertices and codes on both 1.4.3 and current(ish) > master you get > > ``` > In [73]: pth.vertices > Out[74]: > array([[ 2. , 0. ], > [ 2. , 70. ], > [ 2.14285714, 73.10495627], > [ 2.28571429, 75.86005831], > [ 2.42857143, 78.28279883], > [ 2.57142857, 80.39067055], > [ 2.71428571, 82.20116618], > [ 2.85714286, 83.73177843], > [ 3. , 85. ], > [ 3.14285714, 86.02332362], > [ 3.28571429, 86.81924198], > [ 3.42857143, 87.40524781], > [ 3.57142857, 87.79883382], > [ 3.71428571, 88.01749271], > [ 3.85714286, 88.0787172 ], > [ 4. , 88. ], > [ 4.14285714, 87.79883382], > [ 4.28571429, 87.49271137], > [ 4.42857143, 87.09912536], > [ 4.57142857, 86.63556851], > [ 4.71428571, 86.11953353], > [ 4.85714286, 85.56851312], > [ 5. , 85. ], > [ 5.14285714, 84.43148688], > [ 5.28571429, 83.88046647], > [ 5.42857143, 83.36443149], > [ 5.57142857, 82.90087464], > [ 5.71428571, 82.50728863], > [ 5.85714286, 82.20116618], > [ 6. , 82. ], > [ 6.14285714, 81.9212828 ], > [ 6.28571429, 81.98250729], > [ 6.42857143, 82.20116618], > [ 6.57142857, 82.59475219], > [ 6.71428571, 83.18075802], > [ 6.85714286, 83.97667638], > [ 7. , 85. ], > [ 7.14285714, 86.26822157], > [ 7.28571429, 87.79883382], > [ 7.42857143, 89.60932945], > [ 7.57142857, 91.71720117], > [ 7.71428571, 94.13994169], > [ 7.85714286, 96.89504373], > [ 8. , 100. ], > [ 8.14285714, 103.47230321], > [ 8.28571429, 107.32944606], > [ 8.42857143, 111.58892128], > [ 8.57142857, 116.26822157], > [ 8.71428571, 121.38483965], > [ 8.85714286, 126.95626822], > [ 9. , 133. ], > [ 9. , 0. ], > [ 2. , 0. ]]) > > In [75]: pth.codes > Out[75]: > array([ 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, > 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, > 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, > 2, 79], dtype=uint8) > > ``` > > which is is both cases closed due to the `closed` kwarg on the `Polygon` > `__init__`, if you change this to `False` you get back open paths. > > The backend API has not changed between 1.4.3 and current master, you > should be able to develop a backend which will work with both. If you have > found API breaks we would really like to know about them! > > Tom > > On Fri, Aug 14, 2015 at 11:26 AM Jens Nielsen > wrote: > >> I can reproduce the problem with the GTK backend but not the GTKAgg or >> GTKCairo backends. Unless you have some specific reason for using the GTK >> backend I would strongly recommend against it. It is untested, >> unmaintained and officially discouraged: >> http://matplotlib.org/faq/usage_faq.html#what-is-a-backend I would >> recommend you to use GTKAgg instead. >> >> Furthermore the GDK toolkit, used in that backend, has been dropped from >> GTK3 which officially uses Cairo internally and thus Matplotlib only >> supports GTK3Agg and GTK3Cario >> >> I guess the issue is likely a result of the large C++ refactoring in >> master. >> >> best >> Jens >> >> >> >> >> fre. 14. aug. 2015 kl. 15.21 skrev Thomas Caswell : >> >>> Please keep all discussion on the mailing list ( >>> matplotlib-devel at python.org). >>> >>> Being pedantic about versions, current master is v1.5.0dev1 , not 1.5.1 >>> (which will be the first bug fix release in the 1.5 series which may or may >>> not ever happen). >>> >>> I don't have gtk installed to easily test this and it looks fine with >>> qt4agg, can you provide a minimal script and the code paths from a simple >>> polygon? >>> >>> Tom >>> >>> On Fri, Aug 14, 2015 at 9:05 AM Andr?s Vargas >>> wrote: >>> >>>> Hello Tom, >>>> >>>> Thanks for your prompt reply. I am using the function >>>> path.to_polygons() and that gives me a non-closed path in matplotlib 1.4.3 >>>> (last stable release) and give me a closed path in 1.5.1 (master from >>>> github). You can see the problem if you run integral_demo.py with >>>> matplotlib 1.5.1 master with matplotlib.use('gtk'). >>>> >>>> Thanks, Andres >>>> >>> >>>> On Fri, Aug 14, 2015 at 8:13 AM, Thomas Caswell >>>> wrote: >>>> >>>>> Did you mean 1.4.1 instead of 1.5.1 ? >>>>> >>>>> Exactly which paths are you looking at and how are you generating then >>>>> on the mpl side? We have many ways to generate the paths and there maybe >>>>> inconsistence in how closed paths are handled. >>>>> >>>>> Tom >>>>> >>>>> On Wed, Aug 12, 2015, 1:57 PM Andr?s Vargas >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> My name is Andres I am developing a backend for kivy. I was initially >>>>>> developing for 1.5.1 and I found that the paths are coming with the initial >>>>>> vertex at the end of the list. Does anyone know whether this is change in >>>>>> the way paths are sent ? and how can be fixed coming from 1.4.3 since I am >>>>>> developing the backend for that version. >>>>>> >>>>>> Thanks, Andres >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Matplotlib-devel mailing list >>>>>> Matplotlib-devel at lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- [array([[ 0., 0.], [ 101., 0.]]), array([[ 0., 101.], [ 0., 0.]])] [array([[ 80., 48.], [ 101., 48.]]), array([[ 80., 101.], [ 80., 48.]])] [array([[ 80., 48.], [ 101., 48.]]), array([[ 80., 101.], [ 80., 48.]])] [array([[ 179.2, 48. ]])] [array([[ 278.4, 48. ]])] [array([[ 377.6, 48. ]])] [array([[ 476.8, 48. ]])] [array([[ 114.72, 48. ]])] [array([[ 213.92, 48. ]])] [array([[ 313.12, 48. ]])] [array([[ 412.32, 48. ]])] [array([[ 511.52, 48. ]])] [array([[ 97.36, 220.8 ]])] [array([[ 196.56, 355.2 ]])] [array([[ 295.76, 297.6 ]])] [array([[ 394.96, 374.4 ]])] [array([[ 494.16, 288. ]])] [array([[ 132.08, 259.2 ]])] [array([[ 231.28, 307.2 ]])] [array([[ 330.48, 355.2 ]])] [array([[ 429.68, 211.2 ]])] [array([[ 528.88, 259.2 ]])] [array([[ 80., 432.]])] [array([[ 576., 48.]])] [array([[ 80., 48.], [ 80., 101.]])] [array([[ 80., 48.], [ 101., 48.]])] [array([[ 457.4, 369.2]])] [array([[ 463.8, 401.6]])] [array([[ 463.8, 376.6]])] [array([[ 0., 0.], [ 101., 0.]]), array([[ 0., 101.], [ 0., 0.]])] [array([[ 80., 48.], [ 101., 48.]]), array([[ 80., 101.], [ 80., 48.]])] [array([[ 80., 48.], [ 101., 48.]]), array([[ 80., 101.], [ 80., 48.]])] [array([[ 179.2, 48. ]])] [array([[ 278.4, 48. ]])] [array([[ 377.6, 48. ]])] [array([[ 476.8, 48. ]])] [array([[ 114.72, 48. ]])] [array([[ 213.92, 48. ]])] [array([[ 313.12, 48. ]])] [array([[ 412.32, 48. ]])] [array([[ 511.52, 48. ]])] [array([[ 97.36, 220.8 ]])] [array([[ 196.56, 355.2 ]])] [array([[ 295.76, 297.6 ]])] [array([[ 394.96, 374.4 ]])] [array([[ 494.16, 288. ]])] [array([[ 132.08, 259.2 ]])] [array([[ 231.28, 307.2 ]])] [array([[ 330.48, 355.2 ]])] [array([[ 429.68, 211.2 ]])] [array([[ 528.88, 259.2 ]])] [array([[ 80., 432.]])] [array([[ 576., 48.]])] [array([[ 80., 48.], [ 80., 101.]])] [array([[ 80., 48.], [ 101., 48.]])] [array([[ 457.4, 369.2]])] [array([[ 463.8, 401.6]])] [array([[ 463.8, 376.6]])] [array([[ 0., 0.], [ 500., 0.], [ 500., 450.], [ 0., 450.], [ 0., 0.]])] [array([[ 62.5, 45. ], [ 450. , 45. ], [ 450. , 405. ], [ 62.5, 405. ], [ 62.5, 45. ]])] [array([[ 62.5 , 45. ], [ 89.625, 45. ], [ 89.625, 225. ], [ 62.5 , 225. ], [ 62.5 , 45. ]])] [array([[ 140. , 45. ], [ 167.125, 45. ], [ 167.125, 360. ], [ 140. , 360. ], [ 140. , 45. ]])] [array([[ 217.5 , 45. ], [ 244.625, 45. ], [ 244.625, 315. ], [ 217.5 , 315. ], [ 217.5 , 45. ]])] [array([[ 295. , 45. ], [ 322.125, 45. ], [ 322.125, 360. ], [ 295. , 360. ], [ 295. , 45. ]])] [array([[ 372.5 , 45. ], [ 399.625, 45. ], [ 399.625, 288. ], [ 372.5 , 288. ], [ 372.5 , 45. ]])] [array([[ 89.625, 45. ], [ 116.75 , 45. ], [ 116.75 , 270. ], [ 89.625, 270. ], [ 89.625, 45. ]])] [array([[ 167.125, 45. ], [ 194.25 , 45. ], [ 194.25 , 333. ], [ 167.125, 333. ], [ 167.125, 45. ]])] [array([[ 244.625, 45. ], [ 271.75 , 45. ], [ 271.75 , 351. ], [ 244.625, 351. ], [ 244.625, 45. ]])] [array([[ 322.125, 45. ], [ 349.25 , 45. ], [ 349.25 , 225. ], [ 322.125, 225. ], [ 322.125, 45. ]])] [array([[ 399.625, 45. ], [ 426.75 , 45. ], [ 426.75 , 270. ], [ 399.625, 270. ], [ 399.625, 45. ]])] [array([[ 76.0625, 207. ], [ 76.0625, 243. ]])] [array([[ 153.5625, 333. ], [ 153.5625, 387. ]])] [array([[ 231.0625, 279. ], [ 231.0625, 351. ]])] [array([[ 308.5625, 351. ], [ 308.5625, 369. ]])] [array([[ 386.0625, 270. ], [ 386.0625, 306. ]])] [array([[ 103.1875, 243. ], [ 103.1875, 297. ]])] [array([[ 180.6875, 288. ], [ 180.6875, 378. ]])] [array([[ 258.1875, 333. ], [ 258.1875, 369. ]])] [array([[ 335.6875, 198. ], [ 335.6875, 252. ]])] [array([[ 413.1875, 243. ], [ 413.1875, 297. ]])] [array([[ 62.5, 405. ], [ 450. , 405. ]])] [array([[ 450., 45.], [ 450., 405.]])] [array([[ 62.5, 45. ], [ 62.5, 405. ]])] [array([[ 62.5, 45. ], [ 450. , 45. ]])] [array([[ 331.4, 342.2], [ 442. , 342.2], [ 442. , 397. ], [ 331.4, 397. ], [ 331.4, 342.2]])] [array([[ 337.8, 374.6], [ 369.8, 374.6], [ 369.8, 385.8], [ 337.8, 385.8], [ 337.8, 374.6]])] [array([[ 337.8, 349.6], [ 369.8, 349.6], [ 369.8, 360.8], [ 337.8, 360.8], [ 337.8, 349.6]])] -------------- next part -------------- [array([[ 0., 0.], [ 101., 0.], [ 0., 0.], [ 0., 0.]]), array([[ 0., 101.], [ 0., 101.], [ 0., 101.]]), array([[ 0., 0.], [ 0., 0.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.], [ 80., 48.]]), array([[ 80., 101.], [ 80., 101.], [ 80., 101.]]), array([[ 80., 48.], [ 80., 48.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.], [ 80., 48.]]), array([[ 80., 101.], [ 80., 101.], [ 80., 101.]]), array([[ 80., 48.], [ 80., 48.]])] [array([[ 179.2, 48. ], [ 179.2, 48. ]])] [array([[ 278.4, 48. ], [ 278.4, 48. ]])] [array([[ 377.6, 48. ], [ 377.6, 48. ]])] [array([[ 476.8, 48. ], [ 476.8, 48. ]])] [array([[ 114.72, 48. ], [ 114.72, 48. ]])] [array([[ 213.92, 48. ], [ 213.92, 48. ]])] [array([[ 313.12, 48. ], [ 313.12, 48. ]])] [array([[ 412.32, 48. ], [ 412.32, 48. ]])] [array([[ 511.52, 48. ], [ 511.52, 48. ]])] [array([[ 97.36, 220.8 ], [ 97.36, 220.8 ]])] [array([[ 196.56, 355.2 ], [ 196.56, 355.2 ]])] [array([[ 295.76, 297.6 ], [ 295.76, 297.6 ]])] [array([[ 394.96, 374.4 ], [ 394.96, 374.4 ]])] [array([[ 494.16, 288. ], [ 494.16, 288. ]])] [array([[ 132.08, 259.2 ], [ 132.08, 259.2 ]])] [array([[ 231.28, 307.2 ], [ 231.28, 307.2 ]])] [array([[ 330.48, 355.2 ], [ 330.48, 355.2 ]])] [array([[ 429.68, 211.2 ], [ 429.68, 211.2 ]])] [array([[ 528.88, 259.2 ], [ 528.88, 259.2 ]])] [array([[ 80., 432.], [ 80., 432.]])] [array([[ 576., 48.], [ 576., 48.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.]])] [array([[ 80., 48.], [ 80., 101.], [ 80., 48.]])] [array([[ 457.4, 369.2], [ 457.4, 369.2]])] [array([[ 463.8, 401.6], [ 463.8, 401.6]])] [array([[ 463.8, 376.6], [ 463.8, 376.6]])] [array([[ 0., 0.], [ 101., 0.], [ 0., 0.], [ 0., 0.]]), array([[ 0., 101.], [ 0., 101.], [ 0., 101.]]), array([[ 0., 0.], [ 0., 0.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.], [ 80., 48.]]), array([[ 80., 101.], [ 80., 101.], [ 80., 101.]]), array([[ 80., 48.], [ 80., 48.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.], [ 80., 48.]]), array([[ 80., 101.], [ 80., 101.], [ 80., 101.]]), array([[ 80., 48.], [ 80., 48.]])] [array([[ 179.2, 48. ], [ 179.2, 48. ]])] [array([[ 278.4, 48. ], [ 278.4, 48. ]])] [array([[ 377.6, 48. ], [ 377.6, 48. ]])] [array([[ 476.8, 48. ], [ 476.8, 48. ]])] [array([[ 114.72, 48. ], [ 114.72, 48. ]])] [array([[ 213.92, 48. ], [ 213.92, 48. ]])] [array([[ 313.12, 48. ], [ 313.12, 48. ]])] [array([[ 412.32, 48. ], [ 412.32, 48. ]])] [array([[ 511.52, 48. ], [ 511.52, 48. ]])] [array([[ 97.36, 220.8 ], [ 97.36, 220.8 ]])] [array([[ 196.56, 355.2 ], [ 196.56, 355.2 ]])] [array([[ 295.76, 297.6 ], [ 295.76, 297.6 ]])] [array([[ 394.96, 374.4 ], [ 394.96, 374.4 ]])] [array([[ 494.16, 288. ], [ 494.16, 288. ]])] [array([[ 132.08, 259.2 ], [ 132.08, 259.2 ]])] [array([[ 231.28, 307.2 ], [ 231.28, 307.2 ]])] [array([[ 330.48, 355.2 ], [ 330.48, 355.2 ]])] [array([[ 429.68, 211.2 ], [ 429.68, 211.2 ]])] [array([[ 528.88, 259.2 ], [ 528.88, 259.2 ]])] [array([[ 80., 432.], [ 80., 432.]])] [array([[ 576., 48.], [ 576., 48.]])] [array([[ 80., 48.], [ 101., 48.], [ 80., 48.]])] [array([[ 80., 48.], [ 80., 101.], [ 80., 48.]])] [array([[ 457.4, 369.2], [ 457.4, 369.2]])] [array([[ 463.8, 401.6], [ 463.8, 401.6]])] [array([[ 463.8, 376.6], [ 463.8, 376.6]])] [array([[ 0., 0.], [ 500., 0.], [ 500., 450.], [ 0., 450.], [ 0., 0.], [ 0., 0.], [ 0., 0.]])] [array([[ 62.5, 45. ], [ 450. , 45. ], [ 450. , 405. ], [ 62.5, 405. ], [ 62.5, 45. ], [ 62.5, 45. ], [ 62.5, 45. ]])] [array([[ 62.5 , 45. ], [ 89.625, 45. ], [ 89.625, 225. ], [ 62.5 , 225. ], [ 62.5 , 45. ], [ 62.5 , 45. ], [ 62.5 , 45. ]])] [array([[ 140. , 45. ], [ 167.125, 45. ], [ 167.125, 360. ], [ 140. , 360. ], [ 140. , 45. ], [ 140. , 45. ], [ 140. , 45. ]])] [array([[ 217.5 , 45. ], [ 244.625, 45. ], [ 244.625, 315. ], [ 217.5 , 315. ], [ 217.5 , 45. ], [ 217.5 , 45. ], [ 217.5 , 45. ]])] [array([[ 295. , 45. ], [ 322.125, 45. ], [ 322.125, 360. ], [ 295. , 360. ], [ 295. , 45. ], [ 295. , 45. ], [ 295. , 45. ]])] [array([[ 372.5 , 45. ], [ 399.625, 45. ], [ 399.625, 288. ], [ 372.5 , 288. ], [ 372.5 , 45. ], [ 372.5 , 45. ], [ 372.5 , 45. ]])] [array([[ 89.625, 45. ], [ 116.75 , 45. ], [ 116.75 , 270. ], [ 89.625, 270. ], [ 89.625, 45. ], [ 89.625, 45. ], [ 89.625, 45. ]])] [array([[ 167.125, 45. ], [ 194.25 , 45. ], [ 194.25 , 333. ], [ 167.125, 333. ], [ 167.125, 45. ], [ 167.125, 45. ], [ 167.125, 45. ]])] [array([[ 244.625, 45. ], [ 271.75 , 45. ], [ 271.75 , 351. ], [ 244.625, 351. ], [ 244.625, 45. ], [ 244.625, 45. ], [ 244.625, 45. ]])] [array([[ 322.125, 45. ], [ 349.25 , 45. ], [ 349.25 , 225. ], [ 322.125, 225. ], [ 322.125, 45. ], [ 322.125, 45. ], [ 322.125, 45. ]])] [array([[ 399.625, 45. ], [ 426.75 , 45. ], [ 426.75 , 270. ], [ 399.625, 270. ], [ 399.625, 45. ], [ 399.625, 45. ], [ 399.625, 45. ]])] [array([[ 76.0625, 207. ], [ 76.0625, 243. ], [ 76.0625, 207. ]])] [array([[ 153.5625, 333. ], [ 153.5625, 387. ], [ 153.5625, 333. ]])] [array([[ 231.0625, 279. ], [ 231.0625, 351. ], [ 231.0625, 279. ]])] [array([[ 308.5625, 351. ], [ 308.5625, 369. ], [ 308.5625, 351. ]])] [array([[ 386.0625, 270. ], [ 386.0625, 306. ], [ 386.0625, 270. ]])] [array([[ 103.1875, 243. ], [ 103.1875, 297. ], [ 103.1875, 243. ]])] [array([[ 180.6875, 288. ], [ 180.6875, 378. ], [ 180.6875, 288. ]])] [array([[ 258.1875, 333. ], [ 258.1875, 369. ], [ 258.1875, 333. ]])] [array([[ 335.6875, 198. ], [ 335.6875, 252. ], [ 335.6875, 198. ]])] [array([[ 413.1875, 243. ], [ 413.1875, 297. ], [ 413.1875, 243. ]])] [array([[ 62.5, 405. ], [ 450. , 405. ], [ 62.5, 405. ]])] [array([[ 450., 45.], [ 450., 405.], [ 450., 45.]])] [array([[ 62.5, 45. ], [ 450. , 45. ], [ 62.5, 45. ]])] [array([[ 62.5, 45. ], [ 62.5, 405. ], [ 62.5, 45. ]])] [array([[ 331.4, 342.2], [ 442. , 342.2], [ 442. , 397. ], [ 331.4, 397. ], [ 331.4, 342.2], [ 331.4, 342.2], [ 331.4, 342.2]])] [array([[ 337.8, 374.6], [ 369.8, 374.6], [ 369.8, 385.8], [ 337.8, 385.8], [ 337.8, 374.6], [ 337.8, 374.6], [ 337.8, 374.6]])] [array([[ 337.8, 349.6], [ 369.8, 349.6], [ 369.8, 360.8], [ 337.8, 360.8], [ 337.8, 349.6], [ 337.8, 349.6], [ 337.8, 349.6]])] From schut at sarvision.nl Fri Sep 11 12:43:53 2015 From: schut at sarvision.nl (Vincent Schut) Date: Fri, 11 Sep 2015 12:43:53 +0200 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: <55F2B069.8080904@sarvision.nl> On 09/11/15 12:40, Nathaniel Smith wrote: > Did you use pip to install those in-development versions of numpy etc., or just 'setup.py install'? The latter is unfortunately broken in several ways -- what might be biting you here is that it does not install the package metadata (.egg-info or .dist-info) that setuptools and pip need to know whether numpy is installed or not, what version it is, etc. -- this is separate from just having a numpy directory on your pythonpath. (Another thing that will bite you in the future is that when you use distutils/setup.py to install a package, then it's impossible to correctly uninstall or upgrade that package later, because it doesn't make a record of what files were installed.) > > The best / only correct way to install a package from source or a git checkout is 'pip install '; never run setup.py directly. > > (Yes, this is absurd, but I don't make the rules...) Ha, I somtimes have the feeling that absurdity is part of my job description :-) I think my habits are still from the pre-pip era (or at least my pre-pip era). So if I run 'pip install .' from the numpy git checkout folder, it should work? Going to try immediately! Thanks! Vincent. > > -n > > On Sep 11, 2015 03:30, "Vincent Schut" > wrote: > > Hi, > > I'm used to working with unstable versions for most of my numpy/scipy/etc stack (usually from git head). So I have installed numpy 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted matplotlib from git, but when I build this ("python setup.py build", or even with "python setup.py develop --no-deps"), it keeps building it's own numpy 1.9.2 egg, look at this snippet of the output: > > ... > Installed /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg > /usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: Module numpy was already imported from /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being added to sys.path > ... > > Strange thing is, in the beginning matplotlib seems to happily recognize my numpy: > > REQUIRED DEPENDENCIES AND EXTENSIONS > numpy: yes [version 1.11.0.dev0+3397fce] > dateutil: yes [using dateutil version 2.4.2] > pytz: yes [using pytz version 2015.4] > cycler: yes [using cycler version 0.9.0] > tornado: yes [using tornado version 4.2.1] > pyparsing: yes [using pyparsing version 2.0.3] > libagg: yes [Requires patches that have not been merged > upstream. Using local copy.] > freetype: yes [version 2.6.0] > png: yes [version 1.6.18] > qhull: yes [pkg-config information for 'qhull' could not be > found. Using local copy.] > > However, it immediately starts building numpy 1.9.2 after that. > > Having more than one version of numpy (or whatever python package) just messes up my system, I don't want several different versions of numpy to co-exist. Anything I can do to make matplotlib recognize and use my numpy from git? > > Best, > Vincent. > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From bryanv at continuum.io Fri Sep 11 19:09:38 2015 From: bryanv at continuum.io (Bryan Van de Ven) Date: Fri, 11 Sep 2015 12:09:38 -0500 Subject: [Matplotlib-devel] [matplotlib-devel] python data vis Slack channels? In-Reply-To: References: <1B074089-5E96-4F07-8191-AFAFDDAC5D4F@continuum.io> <9A5FA3BB-5B9D-4B6E-9A0F-6825DD5367A6@continuum.io> Message-ID: <2787BCAF-3874-413D-A240-F740C3BD9F34@continuum.io> Not sure, I've not personally set anything up. Bryan > On Sep 8, 2015, at 7:49 PM, Thomas Caswell wrote: > > Did anything come of this? > > Tom > > On Thu, May 7, 2015 at 12:39 PM Nathan Goldbaum wrote: > For what it's worth, there are matplotlib, scipy, and IPython channels on the freenode IRC network. I often answer questions there. > > On Monday, May 4, 2015, Bryan Van de Ven wrote: > We've thought about gitter as well, personally my (slight) preference for Slack is that it does not require a GH account, and also, there is a nice OSS heroku app that provides a really nice "self-invite" button that shows how many users are on, too. You can see it on our test docs deploy: > > http://bokeh.pydata.org/en/test/index.html > > That said it is probably six of one, half dozen of the other. I'm not categorically opposed to looking into gitter some more. > > My hope (and intent) is really to have this as a place for users to congregate and self-support. We do intend to monitor, to the extent we can, but like you there is precious little bandwidth form core devs. > > Bryan > > > > On May 4, 2015, at 11:45 AM, Thomas Caswell wrote: > > > > That sounds reasonable to me. My only concern is getting enough (any?) bandwidth from enough of the core mpl developers. > > > > IPython and scikit image both have gitter rooms running that seem to working well for them as well, is there any reason to go with slack over gitter? > > > > Tom > > > > ---------- Forwarded message --------- > > From: Bryan Van de Ven > > Date: Mon, May 4, 2015 at 11:44 AM > > Subject: python data vis Slack channels? > > To: Michael Droettboom , > > > > > > Hi guys, > > > > We have been experimenting/toying with the idea of using a free Slack channel to provide a place for casual Bokeh user interactions. It occurred that it might be nice to have a single "pyvis.slack.com", that has channels for several OSS python vis libraries in one place. Would you have any interest in a #matplotlib channel there? If there is a better place to submit this proposal, please let me know. > > > > Regards, > > > > Bryan Van de Ven > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel From schut at sarvision.nl Fri Sep 11 21:48:04 2015 From: schut at sarvision.nl (Vincent Schut) Date: Fri, 11 Sep 2015 21:48:04 +0200 Subject: [Matplotlib-devel] matplotlib keeps installing it's own (older) numpy In-Reply-To: References: Message-ID: On 09/11/15 19:44, Paul Hobson wrote: > > > On Fri, Sep 11, 2015 at 10:09 AM, Nathaniel Smith > wrote: > > On Sep 11, 2015 9:13 AM, "Chris Barker" > wrote: > > > > On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith > wrote: > [...] > >> > >> The best / only correct way to install a package from source or a git checkout is 'pip install '; never run setup.py directly. > >> > >> (Yes, this is absurd, but I don't make the rules...) > > > > Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a big hairy mess. > > > > But we *could* force, or at least encourage, the use of setuptools in the numpy build. The reason pip works is because it Monkey-patches setuptools into the install process. > > > > Or maybe I'm am mis-informed - this is very tangled up! > > pip monkeypatches setuptools into the install process... but first it monkeypatches setuptools to fix various weird behaviors. If you just use setuptools directly then you don't get the same thing as pip install. > > Off the top of my head: setuptools will try to easy_install any dependencies, and setuptools will default to installing into a weird directory with a .pth file. I'm not sure that it records what files were installed either. OTOH does at least install .egg-info so that other tools can tell that your package is installed later. > > It is a mess. > > -n > > While we're piling on, I think (it's hard to know) that I ran into an issue where pip was (thankfully) installing a local package with zip_safe=False, but setup.py was only install the egg, making accessing the package's bundled data very difficult. > > So yeah, +1 for "pip install " A mess it is. Pip install seems to work, though, so that's propably a keeper (for as long as it takes). Gonna change the auto update script for my scientific python stack. Thanks for all the interesting comments. :-) Vincent. > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From tcaswell at gmail.com Sat Sep 12 20:27:23 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 12 Sep 2015 18:27:23 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed In-Reply-To: References: Message-ID: I did not understand that the issue was with the `Line2D` object, not with the `Polygon` object is that example. What are the path codes that go with those vertices? Does kivy not support Bezier curves? This is much easier if you include minimal runnable code snippets that demonstrate the issue inline in the email. Tom On Fri, Sep 11, 2015 at 1:51 PM Andr?s Vargas wrote: > I am so sorry I did a wrong use of the reply button. I am currently on > 1.5.dev1 and when I run from examples/showcase/integral_demo.py I see a > line from the last point to the initial as can be seen here > http://imagebin.ca/v/2C7X8CAKZN0g and this happens in all the paths that > are open. > > This is how gtk is doing it: > > http://pastebin.com/MM7YBv4F > > I am doing this: > > http://pastebin.com/7QwJKMv3 > > In 1.4.3 does not have this point at the end of the polygon path. > > Thanks, Andres > > > > On Fri, Aug 14, 2015 at 10:21 AM, Thomas Caswell > wrote: > >> Please keep all discussion on the mailing list ( >> matplotlib-devel at python.org). >> >> Being pedantic about versions, current master is v1.5.0dev1 , not 1.5.1 >> (which will be the first bug fix release in the 1.5 series which may or may >> not ever happen). >> >> I don't have gtk installed to easily test this and it looks fine with >> qt4agg, can you provide a minimal script and the code paths from a simple >> polygon? >> >> Tom >> >> >> On Fri, Aug 14, 2015 at 9:05 AM Andr?s Vargas wrote: >> >>> Hello Tom, >>> >>> Thanks for your prompt reply. I am using the function path.to_polygons() >>> and that gives me a non-closed path in matplotlib 1.4.3 (last stable >>> release) and give me a closed path in 1.5.1 (master from github). You can >>> see the problem if you run integral_demo.py with matplotlib 1.5.1 master >>> with matplotlib.use('gtk'). >>> >>> Thanks, Andres >>> >>> On Fri, Aug 14, 2015 at 8:13 AM, Thomas Caswell >>> wrote: >>> >>>> Did you mean 1.4.1 instead of 1.5.1 ? >>>> >>>> Exactly which paths are you looking at and how are you generating then >>>> on the mpl side? We have many ways to generate the paths and there maybe >>>> inconsistence in how closed paths are handled. >>>> >>>> Tom >>>> >>>> On Wed, Aug 12, 2015, 1:57 PM Andr?s Vargas wrote: >>>> >>>>> Hello, >>>>> >>>>> My name is Andres I am developing a backend for kivy. I was initially >>>>> developing for 1.5.1 and I found that the paths are coming with the initial >>>>> vertex at the end of the list. Does anyone know whether this is change in >>>>> the way paths are sent ? and how can be fixed coming from 1.4.3 since I am >>>>> developing the backend for that version. >>>>> >>>>> Thanks, Andres >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Matplotlib-devel mailing list >>>>> Matplotlib-devel at lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> >>>> >>> >>> >>> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sat Sep 12 20:31:28 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 12 Sep 2015 18:31:28 +0000 Subject: [Matplotlib-devel] Fwd: patch for stream prediction in pdf backend In-Reply-To: <55D71952.9040500@gmx.de> References: <55D6FE4C.4000807@gmx.de> <55D71952.9040500@gmx.de> Message-ID: Cornelius, Thank you. Can you submit that as a PR on github? That is how we do our code review now. Tom On Fri, Sep 11, 2015 at 1:50 PM Cornelius Weig wrote: > Hi, > > I have implemented PNG stream prediction for the pdf backend. It was > marked as a TODO. > > Cheers, > Cornelius > > ------------------- > > Details: > At first I thought about linking to libpng, but I couldn't find an API > for raw encoding of single lines as PDF needs it. Therefore, I > implemented the code in plain python (it makes heavy use of numpy to do > the number crunching). It needs testing with python 3 however... > > I took care of five different encoding modes as specified by RFC 2083: > 10 - noop > 11 - Sub encoding > 12 - Up encoding > 13 - Avg encoding > 14 - Paeth encoding > 15 - Optimal encoding (*) > > (*) For '15', I considered only modes 10-13, because my Paeth > implementation > is not very fast (nor very clean). > > The prediction is done by a static method in the 'Stream' class, which > is called from writeImages. My heuristics have shown (and > http://www.libpng.org/pub/png/book/chapter09.html also mentions it) that > gray-scale data does usually not benefit from stream prediction. > Therefore, the prediction is only applied to color images. > > Finally, I think that the encoding mode is something to be made > adjustable by the user, so that a rcParams['pdf.prediction'] (or > 'filter' or 'pngcompression') setting should be justified. I didn't > touch anything of this, because that's up to you devs. > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sat Sep 12 20:56:34 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 12 Sep 2015 18:56:34 +0000 Subject: [Matplotlib-devel] MEP Process In-Reply-To: <55F21938.3040706@yahoo.co.uk> References: <55F17FBA.5070005@yahoo.co.uk> <55F21938.3040706@yahoo.co.uk> Message-ID: I think we should get rid of the wiki-based MEPs all together, it is just one more place that data can get out of sync. Ideally we make sure that MEPs are merged promptly and worst case changing the number of a MEP before it's PR is merged is an acceptable fallback. Tom On Thu, Sep 10, 2015 at 8:00 PM OceanWolf wrote: > Okay, that suggests the option 1 approach, as that way we can easily see > which numbers we have already allocated, and allows us to easily keep > track of MEP numbers while they still exist only in PR form. I just > want to avoid numbering clashes later. > > If we agree on this, I can go through the wiki and get rid of the MEP > specific pages there, replacing them with a list there, something like: > MEP xx *Discussion*: > > MEP xx *Progress* > updated yet)> > > On 11/09/15 01:18, Nathaniel Smith wrote: > > I believe that what Python does for PEPs is just, when the first draft > > is written you assign the number, and if it ends up being rejected or > > whatever, then oh well, now that's the number for a rejected PEP. They > > just have to be unique, it doesn't matter whether they're strictly in > > order by acceptance date or anything like that. > > > > On Thu, Sep 10, 2015 at 6:03 AM, OceanWolf > > wrote: > >> Hi Matplotlibers, > >> Now that we have moved over to MEPs as pull requests (which I love), we > now > >> need to decide how to "track" these PRs. > >> > >> As far as I see it, we have two options. > >> 1. Keep the wiki, but use it as a stub to track the PR(s). > >> 2. Create a script for Travis that auto-numbers MEPs (and renames the > >> filename of the MEP accordingly?) once an MEP has been merged into > master. > >> > >> What do people think? > >> > >> Best, > >> OceanWolf > >> _______________________________________________ > >> Matplotlib-devel mailing list > >> Matplotlib-devel at python.org > >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sat Sep 12 23:17:15 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 12 Sep 2015 21:17:15 +0000 Subject: [Matplotlib-devel] [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed In-Reply-To: References: Message-ID: >From the documentation in `convert_path_to_polygons` it is for use when the target backend can not deal with Bezier curves. If kivy can deal with Bezier directly I suggest using that instead. On line 698 you are passing in `closed=True` ( https://github.com/andnovar/garden.matplotlib/blob/master/backend_kivy.py#L698), is that intentional? If you do ```python import matplotlib.path as mp pth2 = mp.Path([[ 0., 0.], [ 1., -1.], [ 4., -2.], [ 9., -3.], [ 16., -4.]], None) print(pth2.to_polygons()) ``` you get [array([[ 0., 0.], [ 1., -1.], [ 4., -2.], [ 9., -3.], [ 16., -4.]])] on both master and with 1.4.3 Can you provide a minimal example (like the one above) where `to_polygons()` gives different results between 1.4.3 and master? Tom On Sat, Sep 12, 2015 at 4:54 PM Andr?s Vargas wrote: > Thomas, > > I convert everything to polygon and I decide whether to create a line or a > polygon based on the rgbFace. When rgbFace is None then I create a Mesh > else I create a Line. In 1.4.3 the line formed with the vertices is right > and in 1.5.1 comes with 2 other points repeated as initial points. > I did not use the kivy Bezier since matplotlib has this function that > computes Bezier lines from polygons. The problem is that this method convert_path_to_polygons > is not being consistent from 1.4.3 to 1.5.1 > > > https://github.com/andnovar/garden.matplotlib/blob/master/backend_kivy.py#L695 > > I will send a snippet later on if necessary. > > -- > Andres > > On Sat, Sep 12, 2015 at 2:27 PM, Thomas Caswell > wrote: > >> I did not understand that the issue was with the `Line2D` object, not >> with the `Polygon` object is that example. >> >> What are the path codes that go with those vertices? Does kivy not >> support Bezier curves? >> >> This is much easier if you include minimal runnable code snippets that >> demonstrate the issue inline in the email. >> >> Tom >> >> On Fri, Sep 11, 2015 at 1:51 PM Andr?s Vargas wrote: >> >>> I am so sorry I did a wrong use of the reply button. I am currently on >>> 1.5.dev1 and when I run from examples/showcase/integral_demo.py I see a >>> line from the last point to the initial as can be seen here >>> http://imagebin.ca/v/2C7X8CAKZN0g and this happens in all the paths >>> that are open. >>> >>> This is how gtk is doing it: >>> >>> http://pastebin.com/MM7YBv4F >>> >>> I am doing this: >>> >>> http://pastebin.com/7QwJKMv3 >>> >>> In 1.4.3 does not have this point at the end of the polygon path. >>> >>> Thanks, Andres >>> >>> >>> >>> On Fri, Aug 14, 2015 at 10:21 AM, Thomas Caswell >>> wrote: >>> >>>> Please keep all discussion on the mailing list ( >>>> matplotlib-devel at python.org). >>>> >>>> Being pedantic about versions, current master is v1.5.0dev1 , not 1.5.1 >>>> (which will be the first bug fix release in the 1.5 series which may or may >>>> not ever happen). >>>> >>>> I don't have gtk installed to easily test this and it looks fine with >>>> qt4agg, can you provide a minimal script and the code paths from a simple >>>> polygon? >>>> >>>> Tom >>>> >>>> >>>> On Fri, Aug 14, 2015 at 9:05 AM Andr?s Vargas >>>> wrote: >>>> >>>>> Hello Tom, >>>>> >>>>> Thanks for your prompt reply. I am using the function >>>>> path.to_polygons() and that gives me a non-closed path in matplotlib 1.4.3 >>>>> (last stable release) and give me a closed path in 1.5.1 (master from >>>>> github). You can see the problem if you run integral_demo.py with >>>>> matplotlib 1.5.1 master with matplotlib.use('gtk'). >>>>> >>>>> Thanks, Andres >>>>> >>>>> On Fri, Aug 14, 2015 at 8:13 AM, Thomas Caswell >>>>> wrote: >>>>> >>>>>> Did you mean 1.4.1 instead of 1.5.1 ? >>>>>> >>>>>> Exactly which paths are you looking at and how are you generating >>>>>> then on the mpl side? We have many ways to generate the paths and there >>>>>> maybe inconsistence in how closed paths are handled. >>>>>> >>>>>> Tom >>>>>> >>>>>> On Wed, Aug 12, 2015, 1:57 PM Andr?s Vargas >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> My name is Andres I am developing a backend for kivy. I was >>>>>>> initially developing for 1.5.1 and I found that the paths are coming with >>>>>>> the initial vertex at the end of the list. Does anyone know whether this is >>>>>>> change in the way paths are sent ? and how can be fixed coming from 1.4.3 >>>>>>> since I am developing the backend for that version. >>>>>>> >>>>>>> Thanks, Andres >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Matplotlib-devel mailing list >>>>>>> Matplotlib-devel at lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jks at iki.fi Sun Sep 13 14:35:16 2015 From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=) Date: Sun, 13 Sep 2015 15:35:16 +0300 Subject: [Matplotlib-devel] Fwd: patch for stream prediction in pdf backend References: <55D6FE4C.4000807@gmx.de> <55D71952.9040500@gmx.de> Message-ID: Cornelius Weig writes: > I have implemented PNG stream prediction for the pdf backend. It was > marked as a TODO. The code looks nice! However, the master branch on github (which should become the release candidate pretty soon now) already has an implementation, using libpng. It's true that libpng doesn't have an API that's directly suited to this, but the current implementation simply extracts the IDAT chunks from the png data and writes them into the pdf file. -- Jouni K. Sepp?nen http://www.iki.fi/jks From juichenieder-nabb at yahoo.co.uk Sun Sep 13 17:59:57 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sun, 13 Sep 2015 17:59:57 +0200 Subject: [Matplotlib-devel] Viridis Message-ID: <55F59D7D.4060904@yahoo.co.uk> Okay, perhaps opening a can of worms here, but the more I use viridis (the new colormap), the more I see/notice a rapid change from green to yellow. I love it, it gives a lot of colour for graphs, but it feels a bit uneven at the top, the rest of the colorbar looks more smooth. I especially notice this now as I plot block area data of an (approximately) continuous statistic. Best, OceanWolf From njs at pobox.com Mon Sep 14 04:13:09 2015 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 13 Sep 2015 19:13:09 -0700 Subject: [Matplotlib-devel] Viridis In-Reply-To: <55F59D7D.4060904@yahoo.co.uk> References: <55F59D7D.4060904@yahoo.co.uk> Message-ID: On Sun, Sep 13, 2015 at 8:59 AM, OceanWolf wrote: > Okay, perhaps opening a can of worms here, but the more I use viridis (the > new colormap), the more I see/notice a rapid change from green to yellow. I > love it, it gives a lot of colour for graphs, but it feels a bit uneven at > the top, the rest of the colorbar looks more smooth. I especially notice > this now as I plot block area data of an (approximately) continuous > statistic. It's entirely possible -- for all the fancy color math that went into it, it's still the case that every monitor is different, and every pair of eyes is different, and all the color models are approximations at best. But for the same reason, I'm not sure what can be done to improve it. AFAIK we're already using the best approximations available (and these are fit using pretty much all the available experimental data). -n -- Nathaniel J. Smith -- http://vorpus.org From tcaswell at gmail.com Mon Sep 14 17:57:23 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 14 Sep 2015 15:57:23 +0000 Subject: [Matplotlib-devel] 1.5 release candidate planning Message-ID: Hey all, I plan to cut a 1.5.0rc1 release candidate tonight (probably around 2000 - 2200 EST) The two outstanding feature PRs were - segmented/offset/diverging Norm which looks like it is going to require a fair about of work in the colorbar code to behave correctly - ensure_* which in a phone call with Phil we decided to split off into it's own package Everything else in the 'next point release' milestone is documentation or a bug fix. If anyone has any protests to this please let me know! Given the large number of changes: 11:55 $ git diff v1.4.3 --shortstat 2643 files changed, 246438 insertions(+), 221298 deletions(-) current master as 1.4.3 I expect there to be a couple of RCs. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Sep 14 21:49:42 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 14 Sep 2015 19:49:42 +0000 Subject: [Matplotlib-devel] supported python versions Message-ID: Hey all, I would like to propose the following for which version of python mpl officially supports: - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 - for v2.0 forward we support (2.7, 3.4, 3.5) and allow for new, python3 only, features to be developed for mpl2.1 onward, so long as they do not break any existing functionality in py2.7. We already support all of those versions on master, there is no good reason to drop 2.6 support right before the RC. For 2.0 we should drop 2.6 so that we do not have to maintain a mpl2.0.x py2.6 compatible bug-fix branch. Regarding dropping 2.6 as a supported version I suggest you read/watch the following from Nick Coghlan: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su We are resource limited and those resources would be better spent improving the library and supporting modern version of python. At some point it is unreasonable for people running very old installations of python to expect the the newest versions of down-stream tools to work. If this is important to someone, please step up to mange maintaining a 1.5.x bug-fix branch which will maintain 2.6 compatibility. Dropping 2.6 will also free us to being using OrderedDict and several other language features added in 2.7. Regarding dropping 3.3, every survey has shown that among the users who have adopted py3, a vast majority are using the newest version so supporting and testing against the older versions of 3 is not worth the effort. In all cases, versions of mpl that currently work on legacy versions of python will continue to work. Thanks to Eric, Mike, and Phil who have this a read over. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Mon Sep 14 22:17:23 2015 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 14 Sep 2015 13:17:23 -0700 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: Message-ID: It seems like a good idea in general to me, but doesn't it kinda undermine the "2.0 is style changes only" idea/messaging? I assume the maintenance burden of supporting the old versions in 2.0 won't be large compared to 1.5 given this... Maybe 2.1 (or 1.5!) would be a better place to draw the line? On Sep 14, 2015 12:49 PM, "Thomas Caswell" wrote: > Hey all, > > I would like to propose the following for which version of python mpl > officially supports: > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > - for v2.0 forward we support (2.7, 3.4, 3.5) > > and allow for new, python3 only, features to be developed for mpl2.1 > onward, so long as they do not break any existing functionality in py2.7. > > We already support all of those versions on master, there is no good > reason to drop 2.6 support right before the RC. For 2.0 we should drop 2.6 > so that we do not have to maintain a mpl2.0.x py2.6 compatible bug-fix > branch. > > Regarding dropping 2.6 as a supported version I suggest you read/watch the > following from Nick Coghlan: > > > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > > http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su > > We are resource limited and those resources would be better spent > improving the library and supporting modern version of python. At some > point it is unreasonable for people running very old installations of > python to expect the the newest versions of down-stream tools to work. If > this is important to someone, please step up to mange maintaining a 1.5.x > bug-fix branch which will maintain 2.6 compatibility. > > Dropping 2.6 will also free us to being using OrderedDict and several > other language features added in 2.7. > > Regarding dropping 3.3, every survey has shown that among the users who > have adopted py3, a vast majority are using the newest version so > supporting and testing against the older versions of 3 is not worth the > effort. > > In all cases, versions of mpl that currently work on legacy versions of > python will continue to work. > > Thanks to Eric, Mike, and Phil who have this a read over. > > Tom > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue Sep 15 05:59:23 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 15 Sep 2015 03:59:23 +0000 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series Message-ID: Please give it a try! (linux64 conda builds are available on the tacaswell anaconda.org channel) https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 This release contains many new features. The highlights include: - the object oriented API will now automatically re-draw the figure when working in the command line - automatic unpacking of labeled data into most plotting functions - arbitrary style cycling - four new perceptually linear color maps - mouse-over for pixel values with `imshow` - many new rcparams In addition there are significant improvements to `nbagg` and a complete overhaul of the c++ bindings to AGG. Please see the drafts of the [full whats new]( http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) and [api changes]( http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jks at iki.fi Tue Sep 15 06:42:03 2015 From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=) Date: Tue, 15 Sep 2015 07:42:03 +0300 Subject: [Matplotlib-devel] supported python versions References: Message-ID: Thomas Caswell writes: > I would like to propose the following for which version of python mpl > officially supports: > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > - for v2.0 forward we support (2.7, 3.4, 3.5) I agree. I think for a long time the matplotlib policy was to support the two latest Python releases, although of course there was no deliberate effort to break earlier Pythons. Python 2 is of course a special case, but since Python 2.7 came out in 2010, I think dropping support for Python 2.6 should be fine in 2015. -- Jouni K. Sepp?nen http://www.iki.fi/jks From cgohlke at uci.edu Tue Sep 15 07:50:14 2015 From: cgohlke at uci.edu (Christoph Gohlke) Date: Mon, 14 Sep 2015 22:50:14 -0700 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: Message-ID: <55F7B196.9010408@uci.edu> On 9/14/2015 8:59 PM, Thomas Caswell wrote: > Please give it a try! (linux64 conda builds are available on the > tacaswell anaconda.org channel) > > https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > This release contains many new features. The highlights include: > > - the object oriented API will now automatically re-draw the figure > when working in the command line > - automatic unpacking of labeled data into most plotting functions > - arbitrary style cycling > - four new perceptually linear color maps > - mouse-over for pixel values with `imshow` > - many new rcparams > In addition there are significant improvements to `nbagg` and a complete > overhaul of the c++ bindings to AGG. > > Please see the drafts of the [full whats > new](http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > and [api > changes](http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) > > Hi, where do I upload the Windows binaries? Sourceforge? What is the oldest supported numpy version? Numpy 1.6.2 no longer works. I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). Christoph From juichenieder-nabb at yahoo.co.uk Tue Sep 15 12:28:35 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Tue, 15 Sep 2015 12:28:35 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: Message-ID: <55F7F2D3.5020200@yahoo.co.uk> I don't think it does undermine 2.0's philosophy of "style changes only" as this doesn't affect the code in anyway as we don't add in any new features in 2.0, therefore MPL-2.0 will still work fine with python-2.6, we just won't officially support python-2.6 with version 2.0, and should we have minor releases (2.0.1) then we don't have to worry about py-2.6. 2.0 feels like a more appropriate place to drop it. Best, OceanWolf On 14/09/15 22:17, Nathaniel Smith wrote: > > It seems like a good idea in general to me, but doesn't it kinda > undermine the "2.0 is style changes only" idea/messaging? I assume the > maintenance burden of supporting the old versions in 2.0 won't be > large compared to 1.5 given this... Maybe 2.1 (or 1.5!) would be a > better place to draw the line? > > On Sep 14, 2015 12:49 PM, "Thomas Caswell" > wrote: > > Hey all, > > I would like to propose the following for which version of python > mpl officially supports: > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > - for v2.0 forward we support (2.7, 3.4, 3.5) > > and allow for new, python3 only, features to be developed for > mpl2.1 onward, so long as they do not break any existing > functionality in py2.7. > > We already support all of those versions on master, there is no > good reason to drop 2.6 support right before the RC. For 2.0 we > should drop 2.6 so that we do not have to maintain a mpl2.0.x > py2.6 compatible bug-fix branch. > > Regarding dropping 2.6 as a supported version I suggest you > read/watch the following from Nick Coghlan: > > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su > > We are resource limited and those resources would be better spent > improving the library and supporting modern version of python. At > some point it is unreasonable for people running very old > installations of python to expect the the newest versions of > down-stream tools to work. If this is important to someone, > please step up to mange maintaining a 1.5.x bug-fix branch which > will maintain 2.6 compatibility. > > Dropping 2.6 will also free us to being using OrderedDict and > several other language features added in 2.7. > > Regarding dropping 3.3, every survey has shown that among the > users who have adopted py3, a vast majority are using the newest > version so supporting and testing against the older versions of 3 > is not worth the effort. > > In all cases, versions of mpl that currently work on legacy > versions of python will continue to work. > > Thanks to Eric, Mike, and Phil who have this a read over. > > Tom > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at grinta.net Tue Sep 15 13:10:08 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 15 Sep 2015 13:10:08 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: Message-ID: <55F7FC90.40500@grinta.net> Hello, On 14/09/15 21:49, Thomas Caswell wrote: > I would like to propose the following for which version of python mpl > officially supports: > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > - for v2.0 forward we support (2.7, 3.4, 3.5) > > and allow for new, python3 only, features to be developed for mpl2.1 > onward, so long as they do not break any existing functionality in py2.7. I agree that dropping support for python 2.6 may be a good idea if there are real advantages in doing so, but maybe not in release 2.0 that was advertised to be only about style changes. However, I do not see how it may be possible to have python3 only features added in the code-base, without cluttering it with a lot of conditionals imports and versions checks. What are exactly the python3 features you thing may easy the implementation of matplotlib features? How do you plan to make python3 only code coexist with the existing pythin2/3 code? Cheers, Daniele From tcaswell at gmail.com Tue Sep 15 13:56:23 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 15 Sep 2015 11:56:23 +0000 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: <55F7B196.9010408@uci.edu> References: <55F7B196.9010408@uci.edu> Message-ID: Numpy 1.6 should work, we are currently testing against it on travis. And yes, please push the windows binaries to sourceforge. Tom On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke wrote: > On 9/14/2015 8:59 PM, Thomas Caswell wrote: > > Please give it a try! (linux64 conda builds are available on the > > tacaswell anaconda.org channel) > > > > https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > > > This release contains many new features. The highlights include: > > > > - the object oriented API will now automatically re-draw the figure > > when working in the command line > > - automatic unpacking of labeled data into most plotting functions > > - arbitrary style cycling > > - four new perceptually linear color maps > > - mouse-over for pixel values with `imshow` > > - many new rcparams > > In addition there are significant improvements to `nbagg` and a complete > > overhaul of the c++ bindings to AGG. > > > > Please see the drafts of the [full whats > > new]( > http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > > and [api > > changes]( > http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) > > > > > > Hi, > > where do I upload the Windows binaries? Sourceforge? > > What is the oldest supported numpy version? Numpy 1.6.2 no longer works. > I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). > > Christoph > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue Sep 15 15:20:03 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 15 Sep 2015 13:20:03 +0000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <55F7FC90.40500@grinta.net> References: <55F7FC90.40500@grinta.net> Message-ID: Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this as orthogonal to the 'style only' marketing of 2.0. The idea is that 2.0 will still work with 2.6, but we are not committing to the bug-fix releases working with 2.6. The alternative to dropping py2.6 for 2.0 is dropping it for 1.5 and in that, we might as well drop 3.3 for 1.5 as well. My only hesitation is the lead time and that 1.5 will work with 2.6 and 3.3. How about this instead: v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 and when we break something in the 'known to work with' section we just remove it from the listing in the next release (even a micro). Daniele: The plan for python3 only code is to make a new module(s). I think we can be careful about which way dependencies go and only have to have conditional imports in `pyplot`, if at all. The features I am most excited about are keyword-only args (which will help make our APIs which have a tremendous number of pass through kwargs easier to work with/document) and the signature rewriting (which allows for higher-order functions to propagate signatures). No functionality is lost in python2 and if you are using python3 you get the new features (by importing the new modules). If users are committed to python2 support then obviously they do not get to use the new features (ex other libraries), but in my from my personal experience a vast majority of the code I write that uses mpl (that is not in mpl core) is small standalone scripts or at the repl. As more people switch to python3 as their daily driver the number of 'python 3 only projects', very broadly scoped, is going to sky rocket so I think in a year this will be not be a big deal. Ryan: enum and single-dispatch are the most compelling 3.4+ only feature for us, but there are back-ported versions of both. It also makes all of our supported python3 versions in the random dict-iteration camp. I am tempted to suggest we only support 3.5 to get the infix mul operator and then generalized unpacking syntax! (2.7, 3.5 woul To be clear, what I mean by 'supported versions of python' is that if a user reports a bug specific to an older version of python the mpl developers should not feel guilty about not fixing it, but we will consider reasonable patches which fix it. Again, if 2.6 support is critical for anyone, please reach out, we would love to work with you. Tom On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi wrote: > Hello, > > On 14/09/15 21:49, Thomas Caswell wrote: > > I would like to propose the following for which version of python mpl > > officially supports: > > > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > > - for v2.0 forward we support (2.7, 3.4, 3.5) > > > > and allow for new, python3 only, features to be developed for mpl2.1 > > onward, so long as they do not break any existing functionality in py2.7. > > I agree that dropping support for python 2.6 may be a good idea if there > are real advantages in doing so, but maybe not in release 2.0 that was > advertised to be only about style changes. > > However, I do not see how it may be possible to have python3 only > features added in the code-base, without cluttering it with a lot of > conditionals imports and versions checks. What are exactly the python3 > features you thing may easy the implementation of matplotlib features? > How do you plan to make python3 only code coexist with the existing > pythin2/3 code? > > Cheers, > Daniele > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Tue Sep 15 15:44:51 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 15 Sep 2015 09:44:51 -0400 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: <55F7B196.9010408@uci.edu> Message-ID: Christoph, It would also be useful to document any changes needed in the build procedure for python3.5 on Windows. I don't know if the changes needed for py3.5 impacts us or not, but it would be good to know that for sure. Thanks, Ben Root On Tue, Sep 15, 2015 at 7:56 AM, Thomas Caswell wrote: > Numpy 1.6 should work, we are currently testing against it on travis. > > And yes, please push the windows binaries to sourceforge. > > Tom > > On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke wrote: > >> On 9/14/2015 8:59 PM, Thomas Caswell wrote: >> > Please give it a try! (linux64 conda builds are available on the >> > tacaswell anaconda.org channel) >> > >> > https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 >> > >> > This release contains many new features. The highlights include: >> > >> > - the object oriented API will now automatically re-draw the figure >> > when working in the command line >> > - automatic unpacking of labeled data into most plotting functions >> > - arbitrary style cycling >> > - four new perceptually linear color maps >> > - mouse-over for pixel values with `imshow` >> > - many new rcparams >> > In addition there are significant improvements to `nbagg` and a complete >> > overhaul of the c++ bindings to AGG. >> > >> > Please see the drafts of the [full whats >> > new]( >> http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) >> > and [api >> > changes]( >> http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) >> > >> > >> >> Hi, >> >> where do I upload the Windows binaries? Sourceforge? >> >> What is the oldest supported numpy version? Numpy 1.6.2 no longer works. >> I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). >> >> Christoph >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgohlke at uci.edu Tue Sep 15 19:23:23 2015 From: cgohlke at uci.edu (Christoph Gohlke) Date: Tue, 15 Sep 2015 10:23:23 -0700 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: <55F7B196.9010408@uci.edu> Message-ID: <55F8540B.3070200@uci.edu> With numpy 1.6 I get a link error for `PyArray_SetBaseObject` at Apparently that affects not only Windows: Christoph On 9/15/2015 4:56 AM, Thomas Caswell wrote: > Numpy 1.6 should work, we are currently testing against it on travis. > > And yes, please push the windows binaries to sourceforge. > > Tom > > On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke > wrote: > > On 9/14/2015 8:59 PM, Thomas Caswell wrote: > > Please give it a try! (linux64 conda builds are available on the > > tacaswellanaconda.org channel) > > > >https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > > > This release contains many new features. The highlights include: > > > > - the object oriented API will now automatically re-draw the figure > > when working in the command line > > - automatic unpacking of labeled data into most plotting functions > > - arbitrary style cycling > > - four new perceptually linear color maps > > - mouse-over for pixel values with `imshow` > > - many new rcparams > > In addition there are significant improvements to `nbagg` and a complete > > overhaul of the c++ bindings to AGG. > > > > Please see the drafts of the [full whats > > new](http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > > and [api > > changes](http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) > > > > > > Hi, > > where do I upload the Windows binaries? Sourceforge? > > What is the oldest supported numpy version? Numpy 1.6.2 no longer works. > I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). > > Christoph > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From tcaswell at gmail.com Tue Sep 15 20:17:08 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 15 Sep 2015 18:17:08 +0000 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: <55F8540B.3070200@uci.edu> References: <55F7B196.9010408@uci.edu> <55F8540B.3070200@uci.edu> Message-ID: Created an issue for the numpy regression https://github.com/matplotlib/matplotlib/issues/5078 The in-practice minimal version is currently 1.7 On Tue, Sep 15, 2015 at 1:23 PM Christoph Gohlke wrote: > With numpy 1.6 I get a link error for `PyArray_SetBaseObject` at > < > https://github.com/matplotlib/matplotlib/blob/master/src/_backend_gdk.c#L55 > > > > Apparently that affects not only Windows: > > > Christoph > > > On 9/15/2015 4:56 AM, Thomas Caswell wrote: > > Numpy 1.6 should work, we are currently testing against it on travis. > > > > And yes, please push the windows binaries to sourceforge. > > > > Tom > > > > On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke > > wrote: > > > > On 9/14/2015 8:59 PM, Thomas Caswell wrote: > > > Please give it a try! (linux64 conda builds are available on the > > > tacaswellanaconda.org > channel) > > > > > >https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > > > > > This release contains many new features. The highlights include: > > > > > > - the object oriented API will now automatically re-draw the > figure > > > when working in the command line > > > - automatic unpacking of labeled data into most plotting > functions > > > - arbitrary style cycling > > > - four new perceptually linear color maps > > > - mouse-over for pixel values with `imshow` > > > - many new rcparams > > > In addition there are significant improvements to `nbagg` and a > complete > > > overhaul of the c++ bindings to AGG. > > > > > > Please see the drafts of the [full whats > > > new]( > http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > > > and [api > > > changes]( > http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) > > > > > > > > > > Hi, > > > > where do I upload the Windows binaries? Sourceforge? > > > > What is the oldest supported numpy version? Numpy 1.6.2 no longer > works. > > I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). > > > > Christoph > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgohlke at uci.edu Tue Sep 15 20:47:09 2015 From: cgohlke at uci.edu (Christoph Gohlke) Date: Tue, 15 Sep 2015 11:47:09 -0700 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: <55F7B196.9010408@uci.edu> Message-ID: <55F867AD.9040606@uci.edu> The only change is to have Visual Studio 2015 installed (the community edition is free of charge). A related issue: The matplotlib extensions for Python 3.5 depend on the Visual Studio 2015 C/C++ runtime DLLs, specifically vcruntime140.dll and msvcp140.dll. Vcruntime140.dll is installed with Python 3.5.0 final, however not copied to virtual environments. Msvcp140.dll is not distributed with Python 3.5. Possible solutions: 1) ship msvcp140.dll in the matplotlib package directory. Python and other packages might still fail to load, but that's not matplotlib's problem. This is the preferred way to ship dependencies according to Microsoft. I personally dislike shipping system DLLs next to extensions. See also 2) require users to install the "Visual C++ Redistributable for Visual Studio 2015" . This requires administrator privileges. In the long run this will be much less trouble for users. Christoph On 9/15/2015 6:44 AM, Benjamin Root wrote: > Christoph, > > It would also be useful to document any changes needed in the build > procedure for python3.5 on Windows. I don't know if the changes needed > for py3.5 impacts us or not, but it would be good to know that for sure. > > Thanks, > Ben Root > > > On Tue, Sep 15, 2015 at 7:56 AM, Thomas Caswell > wrote: > > Numpy 1.6 should work, we are currently testing against it on travis. > > And yes, please push the windows binaries to sourceforge. > > Tom > > On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke > wrote: > > On 9/14/2015 8:59 PM, Thomas Caswell wrote: > > Please give it a try! (linux64 conda builds are available on the > > tacaswellanaconda.org channel) > > > >https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > > > This release contains many new features. The highlights include: > > > > - the object oriented API will now automatically re-draw the figure > > when working in the command line > > - automatic unpacking of labeled data into most plotting functions > > - arbitrary style cycling > > - four new perceptually linear color maps > > - mouse-over for pixel values with `imshow` > > - many new rcparams > > In addition there are significant improvements to `nbagg` and a complete > > overhaul of the c++ bindings to AGG. > > > > Please see the drafts of the [full whats > > new](http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > > and [api > > changes](http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) > > > > > > Hi, > > where do I upload the Windows binaries? Sourceforge? > > What is the oldest supported numpy version? Numpy 1.6.2 no > longer works. > I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). > > Christoph > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > From jks at iki.fi Tue Sep 15 21:01:16 2015 From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=) Date: Tue, 15 Sep 2015 22:01:16 +0300 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series References: <55F7B196.9010408@uci.edu> <55F8540B.3070200@uci.edu> Message-ID: Could someone who uses backend_gdk actively and has numpy 1.6 test my proposed fix? It compiles and imports for me, but that's not much of a test yet. Drawing raster images should exercise the relevant code. Jouni Christoph Gohlke writes: > With numpy 1.6 I get a link error for `PyArray_SetBaseObject` at > > > Apparently that affects not only Windows: > > > Christoph > > > On 9/15/2015 4:56 AM, Thomas Caswell wrote: >> Numpy 1.6 should work, we are currently testing against it on travis. >> >> And yes, please push the windows binaries to sourceforge. >> >> Tom >> >> On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke > > wrote: >> >> On 9/14/2015 8:59 PM, Thomas Caswell wrote: >> > Please give it a try! (linux64 conda builds are available on the >> > tacaswellanaconda.org channel) >> > >> >https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 >> > >> > This release contains many new features. The highlights include: >> > >> > - the object oriented API will now automatically re-draw the figure >> > when working in the command line >> > - automatic unpacking of labeled data into most plotting functions >> > - arbitrary style cycling >> > - four new perceptually linear color maps >> > - mouse-over for pixel values with `imshow` >> > - many new rcparams >> > In addition there are significant improvements to `nbagg` and a complete >> > overhaul of the c++ bindings to AGG. >> > >> > Please see the drafts of the [full whats >> > new](http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) >> > and [api >> > changes](http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) >> > >> > >> >> Hi, >> >> where do I upload the Windows binaries? Sourceforge? >> >> What is the oldest supported numpy version? Numpy 1.6.2 no longer works. >> I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). >> >> Christoph >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> -- Jouni K. Sepp?nen http://www.iki.fi/jks From ewm at redtetrahedron.org Tue Sep 15 20:11:06 2015 From: ewm at redtetrahedron.org (Eric Moore) Date: Tue, 15 Sep 2015 14:11:06 -0400 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: <55F8540B.3070200@uci.edu> References: <55F7B196.9010408@uci.edu> <55F8540B.3070200@uci.edu> Message-ID: PyArray_SetBaseObject is new in Numpy 1.7. You have to set the base by hand in in 1.6. An example is here: https://github.com/scipy/scipy/blob/master/scipy/signal/lfilter.c.src#L285-L292 Eric (Sorry for the duplicate Christoph!) On Tue, Sep 15, 2015 at 1:23 PM, Christoph Gohlke wrote: > With numpy 1.6 I get a link error for `PyArray_SetBaseObject` at < > https://github.com/matplotlib/matplotlib/blob/master/src/_backend_gdk.c#L55 > > > > Apparently that affects not only Windows: < > http://stackoverflow.com/questions/28499580> > > Christoph > > > On 9/15/2015 4:56 AM, Thomas Caswell wrote: > >> Numpy 1.6 should work, we are currently testing against it on travis. >> >> And yes, please push the windows binaries to sourceforge. >> >> Tom >> >> On Tue, Sep 15, 2015 at 1:54 AM Christoph Gohlke > > wrote: >> >> On 9/14/2015 8:59 PM, Thomas Caswell wrote: >> > Please give it a try! (linux64 conda builds are available on the >> > tacaswellanaconda.org >> channel) >> > >> >https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 >> > >> > This release contains many new features. The highlights include: >> > >> > - the object oriented API will now automatically re-draw the >> figure >> > when working in the command line >> > - automatic unpacking of labeled data into most plotting >> functions >> > - arbitrary style cycling >> > - four new perceptually linear color maps >> > - mouse-over for pixel values with `imshow` >> > - many new rcparams >> > In addition there are significant improvements to `nbagg` and a >> complete >> > overhaul of the c++ bindings to AGG. >> > >> > Please see the drafts of the [full whats >> > new]( >> http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) >> > and [api >> > changes]( >> http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) >> > >> > >> >> Hi, >> >> where do I upload the Windows binaries? Sourceforge? >> >> What is the oldest supported numpy version? Numpy 1.6.2 no longer >> works. >> I am building rc1 with numpy 1.8.2 (Py <= 3.4) and 1.9.2 (Py 3.5). >> >> Christoph >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Sep 16 10:08:53 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 16 Sep 2015 01:08:53 -0700 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: Message-ID: Hi, On Mon, Sep 14, 2015 at 8:59 PM, Thomas Caswell wrote: > Please give it a try! (linux64 conda builds are available on the tacaswell > anaconda.org channel) > > https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1 > > This release contains many new features. The highlights include: > > - the object oriented API will now automatically re-draw the figure when > working in the command line > - automatic unpacking of labeled data into most plotting functions > - arbitrary style cycling > - four new perceptually linear color maps > - mouse-over for pixel values with `imshow` > - many new rcparams > > In addition there are significant improvements to `nbagg` and a complete > overhaul of the c++ bindings to AGG. > > Please see the drafts of the [full whats > new](http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > and [api > changes](http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0) After some struggle, RC1 wheels up at http://wheels.scipy.org/ Built via : https://travis-ci.org/MacPython/matplotlib-wheels/builds/80587383 If you're testing Python 3.5 you'll need the patched numpy 1.9.2 wheel from nipy.bic.berkeley.edu : pip install -f https://nipy.bic.berkeley.edu/scipy_installers numpy Cheers, Matthew From tillsten at zedat.fu-berlin.de Wed Sep 16 16:21:22 2015 From: tillsten at zedat.fu-berlin.de (Till Stensitzki) Date: Wed, 16 Sep 2015 16:21:22 +0200 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: Message-ID: Am 15.09.2015 um 05:59 schrieb Thomas Caswell: > Please see the drafts of the [full whats new]( > http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5) > and [api changes] A minor suggestion: increase the the savefig.dpi when building the docs. The examples look quite bad, especially the text looks very unsharp. Another suggestion for 2.0: use another default font. Maybe Bitstream Vera Sans just gets badly rendered and the freetype/agg combination of matplotlib, but it looks unsharp for smaller fontsizes. Even for bigger sizes it is still not a very nice font. Tbh I don't know if there are usable free fonts as an alternative, but maybe someone does know. Till From tillsten at zedat.fu-berlin.de Wed Sep 16 16:40:34 2015 From: tillsten at zedat.fu-berlin.de (Till Stensitzki) Date: Wed, 16 Sep 2015 16:40:34 +0200 Subject: [Matplotlib-devel] First release candidate for the 1.5.0 series In-Reply-To: References: Message-ID: Am 16.09.2015 um 04:21 schrieb Till Stensitzki: > A minor suggestion: increase the the savefig.dpi when building the docs. > The examples look quite bad, especially the text looks very unsharp. > Btw i check the matplotlib/doc/matplotlibrc file and seems the dpi is set 80. Till From andnovar at gmail.com Sat Sep 12 22:54:52 2015 From: andnovar at gmail.com (=?UTF-8?Q?Andr=C3=A9s_Vargas?=) Date: Sat, 12 Sep 2015 16:54:52 -0400 Subject: [Matplotlib-devel] [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed In-Reply-To: References: Message-ID: Thomas, I convert everything to polygon and I decide whether to create a line or a polygon based on the rgbFace. When rgbFace is None then I create a Mesh else I create a Line. In 1.4.3 the line formed with the vertices is right and in 1.5.1 comes with 2 other points repeated as initial points. I did not use the kivy Bezier since matplotlib has this function that computes Bezier lines from polygons. The problem is that this method convert_path_to_polygons is not being consistent from 1.4.3 to 1.5.1 https://github.com/andnovar/garden.matplotlib/blob/master/backend_kivy.py#L695 I will send a snippet later on if necessary. -- Andres On Sat, Sep 12, 2015 at 2:27 PM, Thomas Caswell wrote: > I did not understand that the issue was with the `Line2D` object, not with > the `Polygon` object is that example. > > What are the path codes that go with those vertices? Does kivy not > support Bezier curves? > > This is much easier if you include minimal runnable code snippets that > demonstrate the issue inline in the email. > > Tom > > On Fri, Sep 11, 2015 at 1:51 PM Andr?s Vargas wrote: > >> I am so sorry I did a wrong use of the reply button. I am currently on >> 1.5.dev1 and when I run from examples/showcase/integral_demo.py I see a >> line from the last point to the initial as can be seen here >> http://imagebin.ca/v/2C7X8CAKZN0g and this happens in all the paths that >> are open. >> >> This is how gtk is doing it: >> >> http://pastebin.com/MM7YBv4F >> >> I am doing this: >> >> http://pastebin.com/7QwJKMv3 >> >> In 1.4.3 does not have this point at the end of the polygon path. >> >> Thanks, Andres >> >> >> >> On Fri, Aug 14, 2015 at 10:21 AM, Thomas Caswell >> wrote: >> >>> Please keep all discussion on the mailing list ( >>> matplotlib-devel at python.org). >>> >>> Being pedantic about versions, current master is v1.5.0dev1 , not 1.5.1 >>> (which will be the first bug fix release in the 1.5 series which may or may >>> not ever happen). >>> >>> I don't have gtk installed to easily test this and it looks fine with >>> qt4agg, can you provide a minimal script and the code paths from a simple >>> polygon? >>> >>> Tom >>> >>> >>> On Fri, Aug 14, 2015 at 9:05 AM Andr?s Vargas >>> wrote: >>> >>>> Hello Tom, >>>> >>>> Thanks for your prompt reply. I am using the function >>>> path.to_polygons() and that gives me a non-closed path in matplotlib 1.4.3 >>>> (last stable release) and give me a closed path in 1.5.1 (master from >>>> github). You can see the problem if you run integral_demo.py with >>>> matplotlib 1.5.1 master with matplotlib.use('gtk'). >>>> >>>> Thanks, Andres >>>> >>>> On Fri, Aug 14, 2015 at 8:13 AM, Thomas Caswell >>>> wrote: >>>> >>>>> Did you mean 1.4.1 instead of 1.5.1 ? >>>>> >>>>> Exactly which paths are you looking at and how are you generating then >>>>> on the mpl side? We have many ways to generate the paths and there maybe >>>>> inconsistence in how closed paths are handled. >>>>> >>>>> Tom >>>>> >>>>> On Wed, Aug 12, 2015, 1:57 PM Andr?s Vargas >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> My name is Andres I am developing a backend for kivy. I was initially >>>>>> developing for 1.5.1 and I found that the paths are coming with the initial >>>>>> vertex at the end of the list. Does anyone know whether this is change in >>>>>> the way paths are sent ? and how can be fixed coming from 1.4.3 since I am >>>>>> developing the backend for that version. >>>>>> >>>>>> Thanks, Andres >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Matplotlib-devel mailing list >>>>>> Matplotlib-devel at lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>> >>>>> >>>> >>>> >>>> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.buckley at cern.ch Thu Sep 17 22:33:11 2015 From: andy.buckley at cern.ch (Andy Buckley) Date: Thu, 17 Sep 2015 21:33:11 +0100 Subject: [Matplotlib-devel] Suggestion: accept callables as non-xs values arguments Message-ID: <55FB2387.1020203@cern.ch> Hi, Not sure if this is the best place to post this, but I have an API suggestion: as well as iterables, mpl plotting functions could accept callable objects to generate y values, errors, etc.. Specifically, I'm thinking that the list of x values would always need to be specified as an iterable like now, but that the other arguments which currently require an iterable of the same length as the xs could alternatively accept callables that are mapped on to the xs list. The presence of __iter__ or __call__ attributes could be used to determine which approach to use. I searched a bit and couldn't find any previous mention of this idea, and there are callable arguments already used in matplotlib. Thoughts? I'd be happy to help with implementation if there is any interest. Best wishes, Andy From nathan12343 at gmail.com Thu Sep 17 22:44:35 2015 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Thu, 17 Sep 2015 15:44:35 -0500 Subject: [Matplotlib-devel] Creating an interactive figure from the OO interface Message-ID: Hi all, (resending this since I originally sent it to the old sourceforge list, sorry if this double-posts) I see in the matplotlib 1.5 release notes that figures created via the OO interface can now be interactively updated. Does this mean it's now possible to manually create a figure manager using an interactive backend, create a plot using the figure manager and then call the show() method on the figure manager to display the plot in an interactive window, all without (possibly indirectly) importing pyplot? If not, should I just give up and do this via pyplot? I'd like to avoid importing pyplot if possible to avoid crashes on headless sessions. Thanks for your help or advice, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Thu Sep 17 22:52:58 2015 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Thu, 17 Sep 2015 15:52:58 -0500 Subject: [Matplotlib-devel] Creating an interactive figure from the OO interface In-Reply-To: References: Message-ID: Just to follow up with a concrete example, the following code does seem to *draw* a plot on the matplotlib 1.5rc, but the gui loop seems to hang after calling show(), forcing me to kill the python process. ``` import matplotlib.backends.backend_macosx as backend from matplotlib.figure import Figure manager = backend.new_figure_manager(0) fig = manager.canvas.figure ax = fig.add_subplot(1,1,1) ax.plot([1,2,3]) fig.show() backend.show() ``` If I do something similar via pyplot, everything works as expected: ``` import matplotlib.pyplot as plt fig = plt.figure() ax = fig.add_subplot(1,1,1) ax.plot([1,2,3]) plt.show() ``` On Thu, Sep 17, 2015 at 3:44 PM, Nathan Goldbaum wrote: > Hi all, > > (resending this since I originally sent it to the old sourceforge list, > sorry if this double-posts) > > I see in the matplotlib 1.5 release notes that figures created via the OO > interface can now be interactively updated. > > Does this mean it's now possible to manually create a figure manager using > an interactive backend, create a plot using the figure manager and then > call the show() method on the figure manager to display the plot in an > interactive window, all without (possibly indirectly) importing pyplot? If > not, should I just give up and do this via pyplot? I'd like to avoid > importing pyplot if possible to avoid crashes on headless sessions. > > Thanks for your help or advice, > > Nathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Sep 17 23:46:42 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 17 Sep 2015 21:46:42 +0000 Subject: [Matplotlib-devel] Suggestion: accept callables as non-xs values arguments In-Reply-To: <55FB2387.1020203@cern.ch> References: <55FB2387.1020203@cern.ch> Message-ID: Andy, This is exactly the right place to post things like this. Fernando Perez has proposed something similar to me in person. As part of the label data un-packing discussion there was talk of allowing users to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a square root function) which is sort of related to this. What follows is a rather rambling brain dump of me thinking about this ;) Do you want the functions to be evaluated at Artist creation time or Artist draw time? If it is at creation time, see https://github.com/matplotlib/matplotlib/pull/4829 for how we implemented something similar for unpacking labeled data. That might be a reasonable template for how to do this. Would tooling to easily bind plotting functions to the computation be good enough? For controlling any additional args/kwargs to the mapping function we can just use `partial` If it is at _draw_ time, I am a bit more skeptical. But if you can change the x data, the rest of the data _should_ recompute so that would probably be a better way to do it long term, but will require much more invasive changes to the library. We already have a fair number of mapping functions internally (ex, the whole transform stack and the data -> norm -> cmap chain), I wonder if there is a way to generalize any of that? I am also a bit concerned that this will balloon quickly, for example, for people plotting histograms, they may want the yerr to be a function of the y-value (ex Poisson error), not the x-value. The complexity required to express everything that would need to be done once we start to go down this road is a bit daunting. I have been thinking for a while (like a year) about a massive API re-working (which I owe the list a long write up on!), I have heard you and will think about how to integrate this. One other concern is that our top-level API is _too_ magical rather than not magical enough. Tom On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley wrote: > Hi, > > Not sure if this is the best place to post this, but I have an API > suggestion: as well as iterables, mpl plotting functions could accept > callable objects to generate y values, errors, etc.. > > Specifically, I'm thinking that the list of x values would always need > to be specified as an iterable like now, but that the other arguments > which currently require an iterable of the same length as the xs could > alternatively accept callables that are mapped on to the xs list. The > presence of __iter__ or __call__ attributes could be used to determine > which approach to use. > > I searched a bit and couldn't find any previous mention of this idea, > and there are callable arguments already used in matplotlib. Thoughts? > I'd be happy to help with implementation if there is any interest. > > Best wishes, > Andy > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Sep 17 23:50:28 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 17 Sep 2015 21:50:28 +0000 Subject: [Matplotlib-devel] Creating an interactive figure from the OO interface In-Reply-To: References: Message-ID: If you are not going through pyplot you may have to manage starting/integrating with the gui main-loop your self. There is an on-going project (and one failed project) to pull apart `new_figure_manager` and `pyplot`. Tom On Thu, Sep 17, 2015 at 4:53 PM Nathan Goldbaum wrote: > Just to follow up with a concrete example, the following code does seem to > *draw* a plot on the matplotlib 1.5rc, but the gui loop seems to hang after > calling show(), forcing me to kill the python process. > > ``` > import matplotlib.backends.backend_macosx as backend > from matplotlib.figure import Figure > > manager = backend.new_figure_manager(0) > fig = manager.canvas.figure > ax = fig.add_subplot(1,1,1) > ax.plot([1,2,3]) > fig.show() > backend.show() > ``` > > If I do something similar via pyplot, everything works as expected: > > ``` > import matplotlib.pyplot as plt > fig = plt.figure() > ax = fig.add_subplot(1,1,1) > ax.plot([1,2,3]) > plt.show() > ``` > > On Thu, Sep 17, 2015 at 3:44 PM, Nathan Goldbaum > wrote: > >> Hi all, >> >> (resending this since I originally sent it to the old sourceforge list, >> sorry if this double-posts) >> >> I see in the matplotlib 1.5 release notes that figures created via the OO >> interface can now be interactively updated. >> >> Does this mean it's now possible to manually create a figure manager >> using an interactive backend, create a plot using the figure manager and >> then call the show() method on the figure manager to display the plot in an >> interactive window, all without (possibly indirectly) importing pyplot? If >> not, should I just give up and do this via pyplot? I'd like to avoid >> importing pyplot if possible to avoid crashes on headless sessions. >> >> Thanks for your help or advice, >> >> Nathan >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Sep 18 00:15:49 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 17 Sep 2015 22:15:49 +0000 Subject: [Matplotlib-devel] Fwd: Creating an interactive figure from the OO interface In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Thomas Caswell Date: Thu, Sep 17, 2015, 15:15 Subject: Re: [Matplotlib-devel] Creating an interactive figure from the OO interface To: Nathan Goldbaum It is backend dependent and when ever i try to explain it mdehoon tells me i am wrong (and i believe him about that). To address your original question, i will be more clear in the finial release notes. The new feature is that using the OO interface on artists in figures created by pyplot causes automatic redrawing. Tom On Thu, Sep 17, 2015, 14:52 Nathan Goldbaum wrote: On Thu, Sep 17, 2015 at 4:50 PM, Thomas Caswell wrote: If you are not going through pyplot you may have to manage starting/integrating with the gui main-loop your self. Is there an example of how to integrate with a GUI event loop somewhere? There is an on-going project (and one failed project) to pull apart `new_figure_manager` and `pyplot`. Cool! For now I'm tempted to restrict this functionality to nbagg, which does seem to work properly. Tom On Thu, Sep 17, 2015 at 4:53 PM Nathan Goldbaum wrote: Just to follow up with a concrete example, the following code does seem to *draw* a plot on the matplotlib 1.5rc, but the gui loop seems to hang after calling show(), forcing me to kill the python process. ``` import matplotlib.backends.backend_macosx as backend from matplotlib.figure import Figure manager = backend.new_figure_manager(0) fig = manager.canvas.figure ax = fig.add_subplot(1,1,1) ax.plot([1,2,3]) fig.show() backend.show() ``` If I do something similar via pyplot, everything works as expected: ``` import matplotlib.pyplot as plt fig = plt.figure() ax = fig.add_subplot(1,1,1) ax.plot([1,2,3]) plt.show() ``` On Thu, Sep 17, 2015 at 3:44 PM, Nathan Goldbaum wrote: Hi all, (resending this since I originally sent it to the old sourceforge list, sorry if this double-posts) I see in the matplotlib 1.5 release notes that figures created via the OO interface can now be interactively updated. Does this mean it's now possible to manually create a figure manager using an interactive backend, create a plot using the figure manager and then call the show() method on the figure manager to display the plot in an interactive window, all without (possibly indirectly) importing pyplot? If not, should I just give up and do this via pyplot? I'd like to avoid importing pyplot if possible to avoid crashes on headless sessions. Thanks for your help or advice, Nathan _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel at python.org https :// mail.python.org /mailman/ listinfo / matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.buckley at cern.ch Fri Sep 18 18:01:07 2015 From: andy.buckley at cern.ch (Andy Buckley) Date: Fri, 18 Sep 2015 17:01:07 +0100 Subject: [Matplotlib-devel] Suggestion: accept callables as non-xs values arguments In-Reply-To: References: <55FB2387.1020203@cern.ch> Message-ID: <55FC3543.4060605@cern.ch> On 17/09/15 22:46, Thomas Caswell wrote: > Andy, > > This is exactly the right place to post things like this. Phew :-) > Fernando Perez has proposed something similar to me in person. As part > of the label data un-packing discussion there was talk of allowing users > to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a > square root function) which is sort of related to this. That looks like all sorts of more dangerous to me -- it would presumably involve an exec() or equivalent, with security implications. But sure, str funcdef args could be added on top of callables, by the users if not mpl itself! > What follows is a rather rambling brain dump of me thinking about this ;) > > Do you want the functions to be evaluated at Artist creation time or > Artist draw time? > > If it is at creation time, see > https://github.com/matplotlib/matplotlib/pull/4829 for how we > implemented something similar for unpacking labeled data. That might be > a reasonable template for how to do this. Would tooling to easily bind > plotting functions to the computation be good enough? For controlling > any additional args/kwargs to the mapping function we can just use `partial` > > If it is at _draw_ time, I am a bit more skeptical. But if you can > change the x data, the rest of the data _should_ recompute so that would > probably be a better way to do it long term, but will require much more > invasive changes to the library. Heh, I hadn't really been thinking in that sort of detail. I don't really use mpl interactively, and would I *expect* values to update dynamically? Not based on the current behaviour at least, which by construction always requires an explicit recalculation. But I'd defer to interactive users whether (re)draw-time calculation would add enough to be worth the extra trouble. If it's much easier, I guess creation time is the place to start. > We already have a fair number of mapping functions internally (ex, the > whole transform stack and the data -> norm -> cmap chain), I wonder if > there is a way to generalize any of that? Beyond my mpl expertise, I'm afraid! > I am also a bit concerned that this will balloon quickly, for example, > for people plotting histograms, they may want the yerr to be a function > of the y-value (ex Poisson error), not the x-value. The complexity > required to express everything that would need to be done once we start > to go down this road is a bit daunting. Yes, this occurred to me, too. Maybe it's not ambitious enough, but I would be very happy with just parameterising everything on x. But, thinking aloud, a more advanced possibility would be that a ys=callable arg would operate on just x values, an xs=callable arg would operate on just ys, and any other callables would operate on a 2-arg pair (x,y). Obviously only one of xs and ys would be able to be callable. I would hold off generalising beyond that -- YAGNI! Thanks for the quick & positive reply :-) Andy > I have been thinking for a while (like a year) about a massive API > re-working (which I owe the list a long write up on!), I have heard you > and will think about how to integrate this. > > One other concern is that our top-level API is _too_ magical rather than > not magical enough. > > Tom > > On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley > wrote: > > Hi, > > Not sure if this is the best place to post this, but I have an API > suggestion: as well as iterables, mpl plotting functions could accept > callable objects to generate y values, errors, etc.. > > Specifically, I'm thinking that the list of x values would always need > to be specified as an iterable like now, but that the other arguments > which currently require an iterable of the same length as the xs could > alternatively accept callables that are mapped on to the xs list. The > presence of __iter__ or __call__ attributes could be used to determine > which approach to use. > > I searched a bit and couldn't find any previous mention of this idea, > and there are callable arguments already used in matplotlib. Thoughts? > I'd be happy to help with implementation if there is any interest. > > Best wishes, > Andy > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Dr Andy Buckley, Lecturer / Royal Society University Research Fellow Particle Physics Expt Group, University of Glasgow From nathan12343 at gmail.com Fri Sep 18 20:36:18 2015 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Fri, 18 Sep 2015 13:36:18 -0500 Subject: [Matplotlib-devel] nbagg and exceptions raised by callbacks Message-ID: Hi all, I'm having a bit of an issue trying to debug a plot callback using the nbagg backend. The following notebook illustrates the issue: https://gist.github.com/anonymous/e6cb1acd8bfbfda35bf1 If you run that notebook (based on an example in the maptlotlib documentation; I'm using IPython 4.0 and Matplotlib 1.5rc), and try to zoom in on the right-hand panel the exception raised by the ax_update function is never propagated up to the level of the user. If I remove the call to "%matplotlib notebook" from the first cell and run the notebook, a GUI window provided by the MacOSX backend will pop up, and if I zoom into the right-hand plot there, an exception does get printed in the notebook. Is this a bug in the nbagg backend or is there some sort of runtime parameter I need to set to make sure exceptions raised while updating an nbagg plot get propogated back up to my runtime environment? Thanks for your help, Nathan Goldbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwaskom at stanford.edu Fri Sep 18 20:38:52 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Fri, 18 Sep 2015 11:38:52 -0700 Subject: [Matplotlib-devel] Suggestion: accept callables as non-xs values arguments In-Reply-To: <55FC3543.4060605@cern.ch> References: <55FB2387.1020203@cern.ch> <55FC3543.4060605@cern.ch> Message-ID: I think sympy has plotting functions that basically work this way, right? (Though they might only work with sympy function and variable objects, and not generic callables and arrays). Might be worth looking into what they have done, as they've probably wrestled with some of these API problems along the way. On Fri, Sep 18, 2015 at 9:01 AM, Andy Buckley wrote: > On 17/09/15 22:46, Thomas Caswell wrote: > >> Andy, >> >> This is exactly the right place to post things like this. >> > > Phew :-) > > Fernando Perez has proposed something similar to me in person. As part >> of the label data un-packing discussion there was talk of allowing users >> to write expressions in (ex plot('x', 'sqrt(x)', data=df) would plot a >> square root function) which is sort of related to this. >> > > That looks like all sorts of more dangerous to me -- it would presumably > involve an exec() or equivalent, with security implications. But sure, str > funcdef args could be added on top of callables, by the users if not mpl > itself! > > What follows is a rather rambling brain dump of me thinking about this ;) >> >> Do you want the functions to be evaluated at Artist creation time or >> Artist draw time? >> >> If it is at creation time, see >> https://github.com/matplotlib/matplotlib/pull/4829 for how we >> implemented something similar for unpacking labeled data. That might be >> a reasonable template for how to do this. Would tooling to easily bind >> plotting functions to the computation be good enough? For controlling >> any additional args/kwargs to the mapping function we can just use >> `partial` >> >> If it is at _draw_ time, I am a bit more skeptical. But if you can >> change the x data, the rest of the data _should_ recompute so that would >> probably be a better way to do it long term, but will require much more >> invasive changes to the library. >> > > Heh, I hadn't really been thinking in that sort of detail. I don't really > use mpl interactively, and would I *expect* values to update dynamically? > Not based on the current behaviour at least, which by construction always > requires an explicit recalculation. But I'd defer to interactive users > whether (re)draw-time calculation would add enough to be worth the extra > trouble. If it's much easier, I guess creation time is the place to start. > > We already have a fair number of mapping functions internally (ex, the >> whole transform stack and the data -> norm -> cmap chain), I wonder if >> there is a way to generalize any of that? >> > > Beyond my mpl expertise, I'm afraid! > > I am also a bit concerned that this will balloon quickly, for example, >> for people plotting histograms, they may want the yerr to be a function >> of the y-value (ex Poisson error), not the x-value. The complexity >> required to express everything that would need to be done once we start >> to go down this road is a bit daunting. >> > > Yes, this occurred to me, too. > > Maybe it's not ambitious enough, but I would be very happy with just > parameterising everything on x. > > But, thinking aloud, a more advanced possibility would be that a > ys=callable arg would operate on just x values, an xs=callable arg would > operate on just ys, and any other callables would operate on a 2-arg pair > (x,y). Obviously only one of xs and ys would be able to be callable. > > I would hold off generalising beyond that -- YAGNI! > > Thanks for the quick & positive reply :-) > > Andy > > > I have been thinking for a while (like a year) about a massive API >> re-working (which I owe the list a long write up on!), I have heard you >> and will think about how to integrate this. >> >> One other concern is that our top-level API is _too_ magical rather than >> not magical enough. >> >> Tom >> >> On Thu, Sep 17, 2015 at 4:39 PM Andy Buckley > > wrote: >> >> Hi, >> >> Not sure if this is the best place to post this, but I have an API >> suggestion: as well as iterables, mpl plotting functions could accept >> callable objects to generate y values, errors, etc.. >> >> Specifically, I'm thinking that the list of x values would always need >> to be specified as an iterable like now, but that the other arguments >> which currently require an iterable of the same length as the xs could >> alternatively accept callables that are mapped on to the xs list. The >> presence of __iter__ or __call__ attributes could be used to determine >> which approach to use. >> >> I searched a bit and couldn't find any previous mention of this idea, >> and there are callable arguments already used in matplotlib. Thoughts? >> I'd be happy to help with implementation if there is any interest. >> >> Best wishes, >> Andy >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > > -- > Dr Andy Buckley, Lecturer / Royal Society University Research Fellow > Particle Physics Expt Group, University of Glasgow > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Sat Sep 19 00:58:06 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sat, 19 Sep 2015 00:58:06 +0200 Subject: [Matplotlib-devel] Update polar examples? Message-ID: <55FC96FE.7090100@yahoo.co.uk> During my investigation for MEP29 I have noticed in the docs (of figure.py) that: > (For backward compatibility, ``polar=True`` may also be provided, which is equivalent to ``projection='polar'``). But all the polar examples use ``polar=True``, so perhaps we should change the examples to match our current preference (aka ``projection='polar'``)? I say perhaps, because I do feel torn about this, because I *may* want to change this again with MEP29 assuming it gets accepted once I have finished writing it. I guess I err on updating the examples now because it doesn't hurt, and updating them again later if/when we change stuff. Shall I just make a PR of this now? Can it still make 1.5? Would we have to backport it, or will it go straight it? Best, OceanWolf From thomas.robitaille at gmail.com Sat Sep 19 15:37:50 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 19 Sep 2015 15:37:50 +0200 Subject: [Matplotlib-devel] Figure size and DPI for interactive figures Message-ID: Hi everyone, I've been working on trying to make the canvas in the PyQt5 backend have a higher resolution on HiDPI/retina displays: https://github.com/matplotlib/matplotlib/issues/4977 but as part of this, I've become very confused about what we want the *expected* behavior to be for the DPI setting when making interactive figures. Let's say that I start from a clean install of Matplotlib, so the default figure size is (8,6) and the default DPI is 80. If I make a figure with the MacOS X backend, the figure has the same physical size relative to other windows in the OS regardless of whether the display is a retina display or not. However, on retina displays, the canvas is nice and crisp, so in fact the *real* DPI is 160 not 80. In other words, the number of pixels in the canvas is *not* (8 * 80, 6 * 80) but double in each direction. If I now set the DPI to 160, the *figure* size doubles and the actual DPI stays the same. With PyQt4, while there is no support for HiDPI/retina displays, I see the same behavior of the figure size doubling if I double the DPI. In other words, figure size and DPI do not really mean what they should mean for interactive figures, and furthermore for the MacOS X backend on retina displays, the real DPI is double the one in the settings. So what this means is that (based on the MacOS X backend) the real figure size is figsize * dpi, and the real DPI is whatever the screen is. First, is this all expected behavior? And second, should I try and implement the same behavior for PyQt5, namely that on HiDPI displays, a figure with a figure.dpi of 80 will actually look crisp (so it will be internally doubled)? Thanks for any advice! Cheers, Tom From toemossgarcia at gmail.com Sat Sep 19 21:47:38 2015 From: toemossgarcia at gmail.com (toemoss garcia) Date: Sat, 19 Sep 2015 14:47:38 -0500 Subject: [Matplotlib-devel] Gauging interest in a AsynchronousAnimation class Message-ID: Hi, Out of my own needs I developed an animation class that is very similar to FuncAnimation but is drawn asynchronously (not that this couldn't be done with FuncAnimation, this is just a more direct path). Instead of trying to explain the differences off the bat I'll give a base example usage fig, ax = plt.subplots() x = np.arange(0, 2*np.pi, 0.01) line, = ax.plot(x, np.sin(x)) ani = AsyncAnimation(fig,interval=50) fig.show() # starts the first 'draw' without entering the mpl mainloop i = 0 while ani.update(): #update() flushes the animation's queue i += 1 y = np.sin(x+i/10.0) ani.append_artist(line,(x,y)) This is the simplest example, where one frame is queued at a time and `update()` blocks execution until that frame has been rendered (so this is effectively the same as a FuncAnimation). Aesthetically, the difference is that the animation code lives inside a loop instead of a function call. This removes the need to have the animation code pass variables back to the user or doing any global imports of variables which IMHO makes the application code cleaner and more self-contained. Personally, I find this a simpler and more intuitive way to write interactive animation applications. (Alternatively, writing application code inside of a class that uses FuncAnimation gives you similar benefits of cleaner code). The other more significant difference is that having rendering being done asynchronously basically decouples the animation code from the application code, which 1. Makes it trivial to execute the graphics rendering as a separate process 2. Gives the user more flexibility in their application code (you could imagine an application "queueing up" multiple frames at a time, allowing them to render in their own time). Anyway, here is the code as it stands now (most important are the `append_artist` and `update` functions; the rest of the code is very similar to the FuncAnimation class): class AsyncAnimation(Animation): """ Makes an animation by reading from a user filled queue every *interval* milliseconds. User adds to the queue by calling *update_artists*. Note that data is _not_ copied before being put into the queue; if a reference is passed (such as a numpy ndarray) whatever data the reference is pointing to at draw time will be plotted. *init_func* is a function used to draw a clear frame. If not given, the results of drawing from the first item in the frames sequence will be used. This function will be called once before the first frame. *event_source* Default event source to trigger poll of the artist queue. By default this is a timer with an *interval* millisecond timeout. """ def __init__(self,fig,init_func=None,event_source=None,interval=10,blit=True): self._data = deque() self._lag = 0 self._queued = False self._fig = fig self._interval = interval self._init_func = init_func if event_source is None: event_source = fig.canvas.new_timer(interval=self._interval) Animation.__init__(self,fig,event_source=event_source,blit=blit) def new_frame_seq(self): return itertools.count() def _init_draw(self): if self._init_func is not None: self._drawn_artists = self._init_func() for a in self._drawn_artists: a.set_animated(self._blit) def _draw_next_frame(self, *args): # carry on if there's nothing to draw right now if self._data: Animation._draw_next_frame(self,*args) def _draw_frame(self,framedata): artdata = self._data.popleft() artists = [] for (a,d) in artdata: artists.append(a) if d is not None: a.set_data(d) a.set_animated(self._blit) self._drawn_artists = artists def append_artist(self,artist,data=None): self._queue_artists((artist,data),) def extend_artists(self,artists): self._queue_artists(*artists) def _queue_artists(self,*artists): if len(self._data) and self._queued: self._data[-1] += artists return self._queued = True if len(self._data) > self._lag: warnings.warn("Artists queue is behind by %d" % len(self._data)) self._lag = len(self._data) self._data.append(artists) def update(self,block=True): self._queued = False self._fig.canvas.flush_events() if block: while len(self._data) and self.event_source is not None: self._fig.canvas.flush_events() return self.event_source is not None So, I've developed this code enough that it fills my needs, but it needs some work to add in all the expected matplotlib functionality. Is something that would be useful to people? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan12343 at gmail.com Mon Sep 21 17:28:54 2015 From: nathan12343 at gmail.com (Nathan Goldbaum) Date: Mon, 21 Sep 2015 10:28:54 -0500 Subject: [Matplotlib-devel] nbagg and exceptions raised by callbacks In-Reply-To: References: Message-ID: I've opened an issue to track this here: https://github.com/matplotlib/matplotlib/issues/5111 On Fri, Sep 18, 2015 at 1:36 PM, Nathan Goldbaum wrote: > Hi all, > > I'm having a bit of an issue trying to debug a plot callback using the > nbagg backend. > > The following notebook illustrates the issue: > > https://gist.github.com/anonymous/e6cb1acd8bfbfda35bf1 > > If you run that notebook (based on an example in the maptlotlib > documentation; I'm using IPython 4.0 and Matplotlib 1.5rc), and try to zoom > in on the right-hand panel the exception raised by the ax_update function > is never propagated up to the level of the user. If I remove the call to > "%matplotlib notebook" from the first cell and run the notebook, a GUI > window provided by the MacOSX backend will pop up, and if I zoom into the > right-hand plot there, an exception does get printed in the notebook. > > Is this a bug in the nbagg backend or is there some sort of runtime > parameter I need to set to make sure exceptions raised while updating an > nbagg plot get propogated back up to my runtime environment? > > Thanks for your help, > > Nathan Goldbaum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon Sep 21 18:48:39 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 21 Sep 2015 12:48:39 -0400 Subject: [Matplotlib-devel] Update polar examples? In-Reply-To: <55FC96FE.7090100@yahoo.co.uk> References: <55FC96FE.7090100@yahoo.co.uk> Message-ID: Docs can always be updated. +1 On Fri, Sep 18, 2015 at 6:58 PM, OceanWolf wrote: > During my investigation for MEP29 I have noticed in the docs (of > figure.py) that: > > (For backward compatibility, ``polar=True`` may also be provided, which > is equivalent to ``projection='polar'``). > > But all the polar examples use ``polar=True``, so perhaps we should change > the examples to match our current preference (aka ``projection='polar'``)? > I say perhaps, because I do feel torn about this, because I *may* want to > change this again with MEP29 assuming it gets accepted once I have finished > writing it. > > I guess I err on updating the examples now because it doesn't hurt, and > updating them again later if/when we change stuff. > > Shall I just make a PR of this now? Can it still make 1.5? Would we have > to backport it, or will it go straight it? > > Best, > OceanWolf > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Thu Sep 24 05:51:19 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 24 Sep 2015 03:51:19 +0000 Subject: [Matplotlib-devel] Fwd: [NumFOCUS Projects] grant opportunity In-Reply-To: References: Message-ID: If anyone has some downtime and would like to be paid to hack on open source. Submissions are due Sept 30 Tom ---------- Forwarded message --------- From: Gina Helfrich Date: Fri, Sep 18, 2015 at 12:10 PM Subject: [NumFOCUS Projects] grant opportunity To: Hi all, Wanted to bring this opportunity to your attention: Stripe is looking to host three to four developers at their San Francisco office for three months to work full-time on an open-source project. The grant is no-strings-attached: $7,500 per month in addition to desk space at our office and meals during the week. "We want to provide everything needed to focus and have a substantial impact on an open-source project." More info: https://stripe.com/blog/open-source-retreat-2016 The program will run from January 15th until April 15th, 2016 at Stripe HQ in the Mission District of San Francisco. Best, Gina -- *Gina Helfrich, Ph.D.* *Communications Director* NumFOCUS | Open Code, Better Science gina at numfocus.org | 512-222-5449 -- You received this message because you are subscribed to the Google Groups "Fiscally Sponsored Project Representatives" group. To unsubscribe from this group and stop receiving emails from it, send an email to projects+unsubscribe at numfocus.org. To post to this group, send email to projects at numfocus.org. Visit this group at http://groups.google.com/a/numfocus.org/group/projects/. To view this discussion on the web visit https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFhTXRPxOsUubAHE%2BJuXzk%2B%3D4KjJmwXnAWGzNGw%3DPuXnQeiFhg%40mail.gmail.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Fri Sep 25 01:45:42 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 25 Sep 2015 01:45:42 +0200 Subject: [Matplotlib-devel] MPL2 Logo Message-ID: <56048B26.7060903@yahoo.co.uk> Looking at the current logo, I wondered whether we would want to change this as part of the style changes when we release 2.0... as well as marketing our new style, the current logo uses jet to make the graph... Playing around with the examples/api/logo2.py I found changing line 68 to: bar.set_facecolor(cm.viridis(r/8.)) gave pleasing results with the largest wedge getting coloured green (see attached for uncropped version). -------------- next part -------------- A non-text attachment was scrubbed... Name: logo2.png Type: image/png Size: 42478 bytes Desc: not available URL: From ben.v.root at gmail.com Fri Sep 25 02:54:02 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Thu, 24 Sep 2015 20:54:02 -0400 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: <56048B26.7060903@yahoo.co.uk> References: <56048B26.7060903@yahoo.co.uk> Message-ID: I am not against changing the logo, but if we do so, then it should be a much more significant change. I actually like the jet version of the logo better because of the wide variety of colors. Uniform perception isn't a needed trait for graphs like those. On Sep 24, 2015 8:17 PM, "OceanWolf" wrote: > Looking at the current logo, I wondered whether we would want to change > this as part of the style changes when we release 2.0... as well as > marketing our new style, the current logo uses jet to make the graph... > > Playing around with the examples/api/logo2.py I found changing line 68 to: > > bar.set_facecolor(cm.viridis(r/8.)) > > gave pleasing results with the largest wedge getting coloured green (see > attached for uncropped version). > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Fri Sep 25 04:30:13 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 25 Sep 2015 04:30:13 +0200 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: References: <56048B26.7060903@yahoo.co.uk> Message-ID: <5604B1B5.5030402@yahoo.co.uk> Perhaps, I just think we should make a thing of our new colormap, during the whole conversation we talked about stamping our identity with this, the MPL colourmap, well I think we should sing its praises through the homepage. On 25/09/15 02:54, Benjamin Root wrote: > > I am not against changing the logo, but if we do so, then it should be > a much more significant change. I actually like the jet version of the > logo better because of the wide variety of colors. Uniform perception > isn't a needed trait for graphs like those. > > On Sep 24, 2015 8:17 PM, "OceanWolf" > wrote: > > Looking at the current logo, I wondered whether we would want to > change this as part of the style changes when we release 2.0... as > well as marketing our new style, the current logo uses jet to make > the graph... > > Playing around with the examples/api/logo2.py I found changing > line 68 to: > > bar.set_facecolor(cm.viridis(r/8.)) > > gave pleasing results with the largest wedge getting coloured > green (see attached for uncropped version). > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Sep 25 04:43:48 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 25 Sep 2015 02:43:48 +0000 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: References: <56048B26.7060903@yahoo.co.uk> Message-ID: I think any redesign of the logo should go together with a wider ranging overhaul of the website, it's information architecture, and our visual identity. To that end I have enlisted a professional web developer/designer to help us (disclosure, my fiancee). There probably won't be much work done in that direction until after our wedding next month. I like the idea, but am hesitant to make any changes in isolation. Tom On Thu, Sep 24, 2015 at 8:54 PM Benjamin Root wrote: > I am not against changing the logo, but if we do so, then it should be a > much more significant change. I actually like the jet version of the logo > better because of the wide variety of colors. Uniform perception isn't a > needed trait for graphs like those. > On Sep 24, 2015 8:17 PM, "OceanWolf" > wrote: > >> Looking at the current logo, I wondered whether we would want to change >> this as part of the style changes when we release 2.0... as well as >> marketing our new style, the current logo uses jet to make the graph... >> >> Playing around with the examples/api/logo2.py I found changing line 68 to: >> >> bar.set_facecolor(cm.viridis(r/8.)) >> >> gave pleasing results with the largest wedge getting coloured green (see >> attached for uncropped version). >> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Fri Sep 25 05:19:53 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 25 Sep 2015 05:19:53 +0200 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: References: <56048B26.7060903@yahoo.co.uk> Message-ID: <5604BD59.1040602@yahoo.co.uk> Ooh, congratulations to the both of you! On 25/09/15 04:43, Thomas Caswell wrote: > I think any redesign of the logo should go together with a wider > ranging overhaul of the website, it's information architecture, and > our visual identity. To that end I have enlisted a professional web > developer/designer to help us (disclosure, my fiancee). There > probably won't be much work done in that direction until after our > wedding next month. > > I like the idea, but am hesitant to make any changes in isolation. > > Tom > > On Thu, Sep 24, 2015 at 8:54 PM Benjamin Root > wrote: > > I am not against changing the logo, but if we do so, then it > should be a much more significant change. I actually like the jet > version of the logo better because of the wide variety of colors. > Uniform perception isn't a needed trait for graphs like those. > > On Sep 24, 2015 8:17 PM, "OceanWolf" > > wrote: > > Looking at the current logo, I wondered whether we would want > to change this as part of the style changes when we release > 2.0... as well as marketing our new style, the current logo > uses jet to make the graph... > > Playing around with the examples/api/logo2.py I found changing > line 68 to: > > bar.set_facecolor(cm.viridis(r/8.)) > > gave pleasing results with the largest wedge getting coloured > green (see attached for uncropped version). > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Fri Sep 25 02:25:48 2015 From: efiring at hawaii.edu (Eric Firing) Date: Thu, 24 Sep 2015 14:25:48 -1000 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: <56048B26.7060903@yahoo.co.uk> References: <56048B26.7060903@yahoo.co.uk> Message-ID: <5604948C.1060304@hawaii.edu> On 2015/09/24 1:45 PM, OceanWolf wrote: > Looking at the current logo, I wondered whether we would want to change > this as part of the style changes when we release 2.0... as well as > marketing our new style, the current logo uses jet to make the graph... > > Playing around with the examples/api/logo2.py I found changing line 68 to: > > bar.set_facecolor(cm.viridis(r/8.)) > > gave pleasing results with the largest wedge getting coloured green (see > attached for uncropped version). It makes sense to me to use the new colormap. I also noticed a mistake in the first equation, top-left: the first term should be density times the partial derivative of vector velocity with respect to time. Or just divide everything through by density and change the mu to a nu so that density appears only in the pressure gradient term. From jks at iki.fi Sat Sep 26 17:50:17 2015 From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=) Date: Sat, 26 Sep 2015 18:50:17 +0300 Subject: [Matplotlib-devel] Requesting code review Message-ID: I'd like a code review of my pull request: https://github.com/matplotlib/matplotlib/pull/5106 The request is meant to fix a crashing bug: https://github.com/matplotlib/matplotlib/issues/5105 I'll try to explain what changes I'm making in the code. Since I'm not the original author of the code, all claims about the intent of the code are just my interpretation. The major change is to numpy_cpp.h, the set method of the array_view class. This method is supposed to set the fields of the array_view object to match the array passed in. The method can return 0 for failure, or 1 for success. In case of failure, it should free all memory that was allocated. If it replaces the dynamically-allocated member m_arr, the former value needs to have its reference count decremented. The array_view class is templated on the number of dimensions ND, so e.g. a two-dimensional view can only have a two-dimensional buffer. Before this patch, the set method treats zero-dimensional arrays and arrays whose first dimension is zero as compatible with any number of dimensions, but it leaves the m_shape member NULL, which causes the crash. I think PyArray_DIMS(m_arr) returns NULL for zero-dimensional arrays. The zeros array that is used instead is just a constant array of zeros. It is not enough to just return failure in that case, since there are many cases in the code where an empty array is assigned to a view. Instead, I change the logic as follows: 1. if ND is zero and the number of dimensions in the assigned buffer is zero, that counts as a success 2. if the first dimension of the assigned buffer is zero, that counts as a success too, so you can assign an empty buffer that doesn't have the correct number of dimensions 3. otherwise, if the number of dimensions fails to match, that's an error. A smaller change in _path_wrapper.cpp adds a try-catch form around code that uses array_view so that we get more useful error messages at Python level. The code is almost the same as a block above it, and many people consider using exceptions for control flow a bad thing. I wanted to make a minimal change to the code, and this preserves the semantics while improving the error message. -- Jouni K. Sepp?nen http://www.iki.fi/jks From tcaswell at gmail.com Sat Sep 26 23:29:24 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 26 Sep 2015 21:29:24 +0000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: Having not heard anything back, I am going to take that as agreement :) The plan will be: v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 The mechanics of this will be after 2.0: - we reduce the travis test matrix to just 2.7, 3.4, 3.5, - any syntax related bug reports (mostly set literal and ordereddict) are closed as not supported - review and merge 2.6/3.3 specific patches Tom On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell wrote: > Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this as > orthogonal to the 'style only' marketing of 2.0. The idea is that 2.0 will > still work with 2.6, but we are not committing to the bug-fix releases > working with 2.6. The alternative to dropping py2.6 for 2.0 is dropping it > for 1.5 and in that, we might as well drop 3.3 for 1.5 as well. My only > hesitation is the lead time and that 1.5 will work with 2.6 and 3.3. How > about this instead: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > and when we break something in the 'known to work with' section we just > remove it from the listing in the next release (even a micro). > > Daniele: The plan for python3 only code is to make a new module(s). I > think we can be careful about which way dependencies go and only have to > have conditional imports in `pyplot`, if at all. The features I am most > excited about are keyword-only args (which will help make our APIs which > have a tremendous number of pass through kwargs easier to work > with/document) and the signature rewriting (which allows for higher-order > functions to propagate signatures). No functionality is lost in python2 > and if you are using python3 you get the new features (by importing the new > modules). If users are committed to python2 support then obviously they do > not get to use the new features (ex other libraries), but in my from my > personal experience a vast majority of the code I write that uses mpl (that > is not in mpl core) is small standalone scripts or at the repl. As more > people switch to python3 as their daily driver the number of 'python 3 only > projects', very broadly scoped, is going to sky rocket so I think in a year > this will be not be a big deal. > > Ryan: enum and single-dispatch are the most compelling 3.4+ only feature > for us, but there are back-ported versions of both. It also makes all of > our supported python3 versions in the random dict-iteration camp. I am > tempted to suggest we only support 3.5 to get the infix mul operator and > then generalized unpacking syntax! (2.7, 3.5 woul > > To be clear, what I mean by 'supported versions of python' is that if a > user reports a bug specific to an older version of python the mpl > developers should not feel guilty about not fixing it, but we will consider > reasonable patches which fix it. > > Again, if 2.6 support is critical for anyone, please reach out, we would > love to work with you. > > Tom > > On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi > wrote: > >> Hello, >> >> On 14/09/15 21:49, Thomas Caswell wrote: >> > I would like to propose the following for which version of python mpl >> > officially supports: >> > >> > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 >> > - for v2.0 forward we support (2.7, 3.4, 3.5) >> > >> > and allow for new, python3 only, features to be developed for mpl2.1 >> > onward, so long as they do not break any existing functionality in >> py2.7. >> >> I agree that dropping support for python 2.6 may be a good idea if there >> are real advantages in doing so, but maybe not in release 2.0 that was >> advertised to be only about style changes. >> >> However, I do not see how it may be possible to have python3 only >> features added in the code-base, without cluttering it with a lot of >> conditionals imports and versions checks. What are exactly the python3 >> features you thing may easy the implementation of matplotlib features? >> How do you plan to make python3 only code coexist with the existing >> pythin2/3 code? >> >> Cheers, >> Daniele >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Sun Sep 27 04:24:52 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Sat, 26 Sep 2015 22:24:52 -0400 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: Just realized something. Do you mean v2.0.1 or v2.1.0? Also, what is the plan for v1.5.x? If we release a bugfix release of v2.0, does that mean a bugfix release of v1.5 as well? Ben Root On Sep 26, 2015 5:29 PM, "Thomas Caswell" wrote: > Having not heard anything back, I am going to take that as agreement :) > > The plan will be: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > The mechanics of this will be after 2.0: > - we reduce the travis test matrix to just 2.7, 3.4, 3.5, > - any syntax related bug reports (mostly set literal and ordereddict) > are closed as not supported > - review and merge 2.6/3.3 specific patches > > Tom > > On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell wrote: > >> Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this >> as orthogonal to the 'style only' marketing of 2.0. The idea is that 2.0 >> will still work with 2.6, but we are not committing to the bug-fix releases >> working with 2.6. The alternative to dropping py2.6 for 2.0 is dropping it >> for 1.5 and in that, we might as well drop 3.3 for 1.5 as well. My only >> hesitation is the lead time and that 1.5 will work with 2.6 and 3.3. How >> about this instead: >> >> v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and >> 3.3 >> v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and >> 3.3 >> v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 >> >> and when we break something in the 'known to work with' section we just >> remove it from the listing in the next release (even a micro). >> >> Daniele: The plan for python3 only code is to make a new module(s). I >> think we can be careful about which way dependencies go and only have to >> have conditional imports in `pyplot`, if at all. The features I am most >> excited about are keyword-only args (which will help make our APIs which >> have a tremendous number of pass through kwargs easier to work >> with/document) and the signature rewriting (which allows for higher-order >> functions to propagate signatures). No functionality is lost in python2 >> and if you are using python3 you get the new features (by importing the new >> modules). If users are committed to python2 support then obviously they do >> not get to use the new features (ex other libraries), but in my from my >> personal experience a vast majority of the code I write that uses mpl (that >> is not in mpl core) is small standalone scripts or at the repl. As more >> people switch to python3 as their daily driver the number of 'python 3 only >> projects', very broadly scoped, is going to sky rocket so I think in a year >> this will be not be a big deal. >> >> Ryan: enum and single-dispatch are the most compelling 3.4+ only feature >> for us, but there are back-ported versions of both. It also makes all of >> our supported python3 versions in the random dict-iteration camp. I am >> tempted to suggest we only support 3.5 to get the infix mul operator and >> then generalized unpacking syntax! (2.7, 3.5 woul >> >> To be clear, what I mean by 'supported versions of python' is that if a >> user reports a bug specific to an older version of python the mpl >> developers should not feel guilty about not fixing it, but we will consider >> reasonable patches which fix it. >> >> Again, if 2.6 support is critical for anyone, please reach out, we would >> love to work with you. >> >> Tom >> >> On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi >> wrote: >> >>> Hello, >>> >>> On 14/09/15 21:49, Thomas Caswell wrote: >>> > I would like to propose the following for which version of python mpl >>> > officially supports: >>> > >>> > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 >>> > - for v2.0 forward we support (2.7, 3.4, 3.5) >>> > >>> > and allow for new, python3 only, features to be developed for mpl2.1 >>> > onward, so long as they do not break any existing functionality in >>> py2.7. >>> >>> I agree that dropping support for python 2.6 may be a good idea if there >>> are real advantages in doing so, but maybe not in release 2.0 that was >>> advertised to be only about style changes. >>> >>> However, I do not see how it may be possible to have python3 only >>> features added in the code-base, without cluttering it with a lot of >>> conditionals imports and versions checks. What are exactly the python3 >>> features you thing may easy the implementation of matplotlib features? >>> How do you plan to make python3 only code coexist with the existing >>> pythin2/3 code? >>> >>> Cheers, >>> Daniele >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sun Sep 27 04:29:58 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 27 Sep 2015 02:29:58 +0000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: I really meant v2.0.1 (as in the first micro / bug fix release for 2.0. I am hoping to not do 1.5.x bug fix releases unless someone asks for them. We historically have not done bug fixes on the previous released version (ex, we did not do a 1.3.2 and will not do a 1.4.4). Tom On Sat, Sep 26, 2015 at 10:24 PM Benjamin Root wrote: > Just realized something. Do you mean v2.0.1 or v2.1.0? > > Also, what is the plan for v1.5.x? If we release a bugfix release of v2.0, > does that mean a bugfix release of v1.5 as well? > > Ben Root > On Sep 26, 2015 5:29 PM, "Thomas Caswell" wrote: > >> Having not heard anything back, I am going to take that as agreement :) >> >> The plan will be: >> >> v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, >> and 3.3 >> v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, >> and 3.3 >> v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 >> >> The mechanics of this will be after 2.0: >> - we reduce the travis test matrix to just 2.7, 3.4, 3.5, >> - any syntax related bug reports (mostly set literal and ordereddict) >> are closed as not supported >> - review and merge 2.6/3.3 specific patches >> >> Tom >> >> On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell >> wrote: >> >>> Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this >>> as orthogonal to the 'style only' marketing of 2.0. The idea is that 2.0 >>> will still work with 2.6, but we are not committing to the bug-fix releases >>> working with 2.6. The alternative to dropping py2.6 for 2.0 is dropping it >>> for 1.5 and in that, we might as well drop 3.3 for 1.5 as well. My only >>> hesitation is the lead time and that 1.5 will work with 2.6 and 3.3. How >>> about this instead: >>> >>> v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, >>> and 3.3 >>> v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, >>> and 3.3 >>> v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 >>> >>> and when we break something in the 'known to work with' section we just >>> remove it from the listing in the next release (even a micro). >>> >>> Daniele: The plan for python3 only code is to make a new module(s). I >>> think we can be careful about which way dependencies go and only have to >>> have conditional imports in `pyplot`, if at all. The features I am most >>> excited about are keyword-only args (which will help make our APIs which >>> have a tremendous number of pass through kwargs easier to work >>> with/document) and the signature rewriting (which allows for higher-order >>> functions to propagate signatures). No functionality is lost in python2 >>> and if you are using python3 you get the new features (by importing the new >>> modules). If users are committed to python2 support then obviously they do >>> not get to use the new features (ex other libraries), but in my from my >>> personal experience a vast majority of the code I write that uses mpl (that >>> is not in mpl core) is small standalone scripts or at the repl. As more >>> people switch to python3 as their daily driver the number of 'python 3 only >>> projects', very broadly scoped, is going to sky rocket so I think in a year >>> this will be not be a big deal. >>> >>> Ryan: enum and single-dispatch are the most compelling 3.4+ only feature >>> for us, but there are back-ported versions of both. It also makes all of >>> our supported python3 versions in the random dict-iteration camp. I am >>> tempted to suggest we only support 3.5 to get the infix mul operator and >>> then generalized unpacking syntax! (2.7, 3.5 woul >>> >>> To be clear, what I mean by 'supported versions of python' is that if a >>> user reports a bug specific to an older version of python the mpl >>> developers should not feel guilty about not fixing it, but we will consider >>> reasonable patches which fix it. >>> >>> Again, if 2.6 support is critical for anyone, please reach out, we would >>> love to work with you. >>> >>> Tom >>> >>> On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi >>> wrote: >>> >>>> Hello, >>>> >>>> On 14/09/15 21:49, Thomas Caswell wrote: >>>> > I would like to propose the following for which version of python mpl >>>> > officially supports: >>>> > >>>> > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 >>>> > - for v2.0 forward we support (2.7, 3.4, 3.5) >>>> > >>>> > and allow for new, python3 only, features to be developed for mpl2.1 >>>> > onward, so long as they do not break any existing functionality in >>>> py2.7. >>>> >>>> I agree that dropping support for python 2.6 may be a good idea if there >>>> are real advantages in doing so, but maybe not in release 2.0 that was >>>> advertised to be only about style changes. >>>> >>>> However, I do not see how it may be possible to have python3 only >>>> features added in the code-base, without cluttering it with a lot of >>>> conditionals imports and versions checks. What are exactly the python3 >>>> features you thing may easy the implementation of matplotlib features? >>>> How do you plan to make python3 only code coexist with the existing >>>> pythin2/3 code? >>>> >>>> Cheers, >>>> Daniele >>>> >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Matplotlib-devel at python.org >>>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>>> >>> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Sun Sep 27 04:37:16 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sun, 27 Sep 2015 04:37:16 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: <5607565C.4010904@yahoo.co.uk> For those wondering, I think it important to add that (afaik) 2.0 will follow very soon after 1.5, remember we only make an RC change(s) between 2.0 and 1.5... On 27/09/15 04:29, Thomas Caswell wrote: > I really meant v2.0.1 (as in the first micro / bug fix release for 2.0. > > I am hoping to not do 1.5.x bug fix releases unless someone asks for > them. We historically have not done bug fixes on the previous > released version (ex, we did not do a 1.3.2 and will not do a 1.4.4). > > Tom > > On Sat, Sep 26, 2015 at 10:24 PM Benjamin Root > wrote: > > Just realized something. Do you mean v2.0.1 or v2.1.0? > > Also, what is the plan for v1.5.x? If we release a bugfix release > of v2.0, does that mean a bugfix release of v1.5 as well? > > Ben Root > > On Sep 26, 2015 5:29 PM, "Thomas Caswell" > wrote: > > Having not heard anything back, I am going to take that as > agreement :) > > The plan will be: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work > with 2.6, and 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work > with 2.6, and 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work > with 3.3 > > The mechanics of this will be after 2.0: > - we reduce the travis test matrix to just 2.7, 3.4, 3.5, > - any syntax related bug reports (mostly set literal and > ordereddict) are closed as not supported > - review and merge 2.6/3.3 specific patches > > Tom > > On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell > > wrote: > > Nathaniel and Daniele: I think OceanWolf hit it on the > head, I see this as orthogonal to the 'style only' > marketing of 2.0. The idea is that 2.0 will still work > with 2.6, but we are not committing to the bug-fix > releases working with 2.6. The alternative to dropping > py2.6 for 2.0 is dropping it for 1.5 and in that, we might > as well drop 3.3 for 1.5 as well. My only hesitation is > the lead time and that 1.5 will work with 2.6 and 3.3. > How about this instead: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to > work with 2.6, and 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to > work with 2.6, and 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to > work with 3.3 > > and when we break something in the 'known to work with' > section we just remove it from the listing in the next > release (even a micro). > Daniele: The plan for python3 only code is to make a new > module(s). I think we can be careful about which way > dependencies go and only have to have conditional imports > in `pyplot`, if at all. The features I am most excited > about are keyword-only args (which will help make our APIs > which have a tremendous number of pass through kwargs > easier to work with/document) and the signature rewriting > (which allows for higher-order functions to propagate > signatures). No functionality is lost in python2 and if > you are using python3 you get the new features (by > importing the new modules). If users are committed to > python2 support then obviously they do not get to use the > new features (ex other libraries), but in my from my > personal experience a vast majority of the code I write > that uses mpl (that is not in mpl core) is small > standalone scripts or at the repl. As more people switch > to python3 as their daily driver the number of 'python 3 > only projects', very broadly scoped, is going to sky > rocket so I think in a year this will be not be a big deal. > > Ryan: enum and single-dispatch are the most compelling > 3.4+ only feature for us, but there are back-ported > versions of both. It also makes all of our supported > python3 versions in the random dict-iteration camp. I am > tempted to suggest we only support 3.5 to get the infix > mul operator and then generalized unpacking syntax! (2.7, > 3.5 woul > > To be clear, what I mean by 'supported versions of python' > is that if a user reports a bug specific to an older > version of python the mpl developers should not feel > guilty about not fixing it, but we will consider > reasonable patches which fix it. > > Again, if 2.6 support is critical for anyone, please reach > out, we would love to work with you. > > Tom > > On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi > > wrote: > > Hello, > > On 14/09/15 21:49, Thomas Caswell wrote: > > I would like to propose the following for which > version of python mpl > > officially supports: > > > > - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 > > - for v2.0 forward we support (2.7, 3.4, 3.5) > > > > and allow for new, python3 only, features to be > developed for mpl2.1 > > onward, so long as they do not break any existing > functionality in py2.7. > > I agree that dropping support for python 2.6 may be a > good idea if there > are real advantages in doing so, but maybe not in > release 2.0 that was > advertised to be only about style changes. > > However, I do not see how it may be possible to have > python3 only > features added in the code-base, without cluttering it > with a lot of > conditionals imports and versions checks. What are > exactly the python3 > features you thing may easy the implementation of > matplotlib features? > How do you plan to make python3 only code coexist with > the existing > pythin2/3 code? > > Cheers, > Daniele > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at grinta.net Sun Sep 27 14:38:02 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 27 Sep 2015 14:38:02 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: <5607E32A.1010403@grinta.net> On 15/09/15 15:20, Thomas Caswell wrote: > Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this > as orthogonal to the 'style only' marketing of 2.0. The idea is that > 2.0 will still work with 2.6, but we are not committing to the bug-fix > releases working with 2.6. The alternative to dropping py2.6 for 2.0 is > dropping it for 1.5 and in that, we might as well drop 3.3 for 1.5 as > well. My only hesitation is the lead time and that 1.5 will work with > 2.6 and 3.3. How about this instead: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > and when we break something in the 'known to work with' section we just > remove it from the listing in the next release (even a micro). I think this is a horrible idea. What is the difference between supported and "known to work with"? For a given release to be known to work with a give python release, it must be tested with that python release. And it must be fixed if those tests break. Otherwise, what you have is a release that "may work with" a given python release, but this is not very useful to advertise. I'm not saying that we should keep supporting python 2.6, but introducing the concept of "known to work with" as opposed to "supported to work with" is in my opinion a mistake. Dropping support for old python versions is good, but please do that in mayor releases and not in patch level releases. Breaking compatibility in patch level releases is going to cause a lot of troubles to people that need to support those old python releases. > Daniele: The plan for python3 only code is to make a new module(s). I > think we can be careful about which way dependencies go and only have to > have conditional imports in `pyplot`, if at all. The features I am most > excited about are keyword-only args (which will help make our APIs which > have a tremendous number of pass through kwargs easier to work > with/document) and the signature rewriting (which allows for > higher-order functions to propagate signatures). While I agree that those are useful features for the matplotlib API, introducing those only for a few functions (as most of the matplotlib API is constituted by functions imported from the same module) is going to introduce inconsistencies (in an already quite messy API) that would be hard to document, making the library even harder to use. Cheers, Daniele From daniele at grinta.net Sun Sep 27 14:50:33 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 27 Sep 2015 14:50:33 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> Message-ID: <5607E619.3040108@grinta.net> On 26/09/15 23:29, Thomas Caswell wrote: > Having not heard anything back, I am going to take that as agreement :) I believe that taking silence as consent works only if you give a deadline for opinions and veto before hand, not after the fact. > The plan will be: > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > The mechanics of this will be after 2.0: > - we reduce the travis test matrix to just 2.7, 3.4, 3.5, > - any syntax related bug reports (mostly set literal and ordereddict) > are closed as not supported > - review and merge 2.6/3.3 specific patches I still don't understand what "know to work with" means. From the above it seems that it means that "you may be luck and we have not break compatibility, but if we did, then it is on you, we are not going to fix it". With, to me, reads the same as "not supported". Breaking compatibility with python releases in patch version releases is also a terrible idea, in my opinion. Matplotlib release 1.5 is release candidate now, and as far as I know it is supposed to work with python 2.6. What changes are you foreseeing in patch releases of the 1.5 series that will take advantage of breaking compatibility with python 2.6? I believe that matplotlib 1.5 series will be only about bug fixing, and that all development will go into 2.0. I don't really see how bug fixes can be helped by dropping compatibility with old python releases. As for what python releases matplotlib 2.0 should support, I don't have strong opinions. I think dropping python 2.6 and 3.3 support may be reasonable. However, do not change the python release support matrix in patch level releases! Cheers, Daniele From juichenieder-nabb at yahoo.co.uk Sun Sep 27 18:28:57 2015 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Sun, 27 Sep 2015 18:28:57 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <5607E619.3040108@grinta.net> References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> Message-ID: <56081949.9060203@yahoo.co.uk> On 27/09/15 14:50, Daniele Nicolodi wrote: > I still don't understand what "know to work with" means. From the above > it seems that it means that "you may be luck and we have not break > compatibility, but if we did, then it is on you, we are not going to fix > it". With, to me, reads the same as "not supported". > > Breaking compatibility with python releases in patch version releases is > also a terrible idea, in my opinion. Yes, this underpins the reason for changing to "known to work with...", because we don't want to break compatibility in minor versions, but versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3. > Matplotlib release 1.5 is release candidate now, and as far as I know it > is supposed to work with python 2.6. What changes are you foreseeing in > patch releases of the 1.5 series that will take advantage of breaking > compatibility with python 2.6? > > I believe that matplotlib 1.5 series will be only about bug fixing, and > that all development will go into 2.0. I don't really see how bug fixes > can be helped by dropping compatibility with old python releases. We release 2.0 shortly after 1.5 which means 1.5 won't have any patch fixes, and 2.0 contains no new features, but a change to the default colours. But yes, dropping support for python 2.6 allows us use things such as OrderedDict, not saying we will use such things in 2.0.x (assuming we have a 2.0.x release, fingers crossed we find no bugs), but making the change now to the requirements keeps our options open for the future. Best, OceanWolf From tcaswell at gmail.com Sun Sep 27 21:49:36 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 27 Sep 2015 19:49:36 +0000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <56081949.9060203@yahoo.co.uk> References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: We already have this 'know to work with' vs 'supported' distinction, this is the current state of python 3.2 support. We don't test on it, my response to 3.2 specific bugs is 'upgrade', but if we get reasonable, non-destructive patches they will get merged (which we have done, around the 1.4 release, after we dropped 3.2, we merged some patches from Christoph Gohlke which fixed 3.2 on windows). The reality is that we should have had this discussion 6-12 months ago (sorry OceanWolf), instead of on the cusp of a release, and currently master (and hence both the 1.5.0 and 2.0 releases) _will_ work with py2.6 and py3.3 because we are currently testing on them. There is consensus in the core developers that we will not support py2.6/3.3 going forward so the question is what to do about the upcoming releases. The options are: - do not document at all that as far as we know 1.5/2.0 will work on on py2.6 - document that as far as we know mpl does work on py2.6, but are making no commitment to make sure that stays true. I very much like the second option as it is more accurate and gives _any_ support/hope to someone stuck on 2.6. Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which back ports bug fixes in a 2.6 compatibly that would be great, otherwise given the limited resources the project currently has, that is not something we can. I have already linked to this article is this thread, but once more for good measure: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html For reference, debian stable no longer has 2.6 packaged ( https://wiki.debian.org/Python/JessieRoadmap) and RHEL has ways of getting modern python running on older versions. And again, as I have said at the bottom of every email, if there is someone who really needs new features on 2.6, let me know and we will see if we can work something out. Tom On Sun, Sep 27, 2015 at 12:31 PM OceanWolf wrote: > On 27/09/15 14:50, Daniele Nicolodi wrote: > > I still don't understand what "know to work with" means. From the above > > it seems that it means that "you may be luck and we have not break > > compatibility, but if we did, then it is on you, we are not going to fix > > it". With, to me, reads the same as "not supported". > > > > Breaking compatibility with python releases in patch version releases is > > also a terrible idea, in my opinion. > Yes, this underpins the reason for changing to "known to work with...", > because we don't want to break compatibility in minor versions, but > versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3. > > Matplotlib release 1.5 is release candidate now, and as far as I know it > > is supposed to work with python 2.6. What changes are you foreseeing in > > patch releases of the 1.5 series that will take advantage of breaking > > compatibility with python 2.6? > > > > I believe that matplotlib 1.5 series will be only about bug fixing, and > > that all development will go into 2.0. I don't really see how bug fixes > > can be helped by dropping compatibility with old python releases. > We release 2.0 shortly after 1.5 which means 1.5 won't have any patch > fixes, and 2.0 contains no new features, but a change to the default > colours. But yes, dropping support for python 2.6 allows us use things > such as OrderedDict, not saying we will use such things in 2.0.x > (assuming we have a 2.0.x release, fingers crossed we find no bugs), but > making the change now to the requirements keeps our options open for the > future. > > Best, > OceanWolf > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sun Sep 27 21:58:23 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 27 Sep 2015 19:58:23 +0000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: To follow up the following is the matrix of possible 'supported python' tables for the next few releases: A v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and 3.3 v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 cons: 'known to work with' is controversial/confusing, may pick up incompatibilities on a micro release. pros: simple on dev side, lets 2.6/3.3 semi-gracefully fall away. B v1.5.0 is supported in 2.7, 3.4, 3.5 v2.0.0 is supported in 2.7, 3.4, 3.5 v2.0.1 is supported in 2.7, 3.4, 3.5 cons: under-documents the 'real' support, drops 2.6 without much warning pros: simple on dev side C v1.5.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 v2.0.0 is supported in 2.7, 3.4, 3.5 v2.0.1 is supported in 2.7, 3.4, 3.5 cons: muddies the water on 2.0 being 'style only', under documents where 2.0 will work, implicitly commits us to a 2.6 compatible 1.5.x series but I do not anticipate us actually doing a 1.5.x series. My preference is A > C > B. Tom On Sun, Sep 27, 2015 at 3:49 PM Thomas Caswell wrote: > We already have this 'know to work with' vs 'supported' distinction, this > is the current state of python 3.2 support. We don't test on it, my > response to 3.2 specific bugs is 'upgrade', but if we get reasonable, > non-destructive patches they will get merged (which we have done, around > the 1.4 release, after we dropped 3.2, we merged some patches > from Christoph Gohlke which fixed 3.2 on windows). > > The reality is that we should have had this discussion 6-12 months ago > (sorry OceanWolf), instead of on the cusp of a release, and currently > master (and hence both the 1.5.0 and 2.0 releases) _will_ work with py2.6 > and py3.3 because we are currently testing on them. There is consensus in > the core developers that we will not support py2.6/3.3 going forward so the > question is what to do about the upcoming releases. The options are: > > - do not document at all that as far as we know 1.5/2.0 will work on on > py2.6 > - document that as far as we know mpl does work on py2.6, but are making > no commitment to make sure that stays true. > > I very much like the second option as it is more accurate and gives _any_ > support/hope to someone stuck on 2.6. > > Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which > back ports bug fixes in a 2.6 compatibly that would be great, otherwise > given the limited resources the project currently has, that is not > something we can. > > I have already linked to this article is this thread, but once more for > good measure: > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > > For reference, debian stable no longer has 2.6 packaged ( > https://wiki.debian.org/Python/JessieRoadmap) and RHEL has ways of > getting modern python running on older versions. > > And again, as I have said at the bottom of every email, if there is > someone who really needs new features on 2.6, let me know and we will see > if we can work something out. > > Tom > > On Sun, Sep 27, 2015 at 12:31 PM OceanWolf > wrote: > >> On 27/09/15 14:50, Daniele Nicolodi wrote: >> > I still don't understand what "know to work with" means. From the above >> > it seems that it means that "you may be luck and we have not break >> > compatibility, but if we did, then it is on you, we are not going to fix >> > it". With, to me, reads the same as "not supported". >> > >> > Breaking compatibility with python releases in patch version releases is >> > also a terrible idea, in my opinion. >> Yes, this underpins the reason for changing to "known to work with...", >> because we don't want to break compatibility in minor versions, but >> versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3. >> > Matplotlib release 1.5 is release candidate now, and as far as I know it >> > is supposed to work with python 2.6. What changes are you foreseeing in >> > patch releases of the 1.5 series that will take advantage of breaking >> > compatibility with python 2.6? >> > >> > I believe that matplotlib 1.5 series will be only about bug fixing, and >> > that all development will go into 2.0. I don't really see how bug fixes >> > can be helped by dropping compatibility with old python releases. >> We release 2.0 shortly after 1.5 which means 1.5 won't have any patch >> fixes, and 2.0 contains no new features, but a change to the default >> colours. But yes, dropping support for python 2.6 allows us use things >> such as OrderedDict, not saying we will use such things in 2.0.x >> (assuming we have a 2.0.x release, fingers crossed we find no bugs), but >> making the change now to the requirements keeps our options open for the >> future. >> >> Best, >> OceanWolf >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Mon Sep 28 00:24:56 2015 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 27 Sep 2015 15:24:56 -0700 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: To me it just doesn't even make sense to say "2.0.0 supports py26 but 2.0.1 won't" -- "supports" means "if there's a problem, we'll fix it", and the way you fix it is by doing a micro release, so... It sounds like the actual policy is set (no one is willing to commit to doing the work to keep 1.5 or 2.0 working on py26 or py33), and IMHO the simplest way to communicate that policy to users is to just say for both the 1.5.0 and 2.0.0: Supported versions: 2.7, 3.4, 3.5 Other versions (esp. 2.6 and 3.3) might also work, but this is at your own risk. -n On Sep 27, 2015 1:05 PM, "Thomas Caswell" wrote: > To follow up the following is the matrix of possible 'supported python' > tables for the next few releases: > > A > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and > 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > cons: 'known to work with' is controversial/confusing, may pick up > incompatibilities on a micro release. > pros: simple on dev side, lets 2.6/3.3 semi-gracefully fall away. > > B > v1.5.0 is supported in 2.7, 3.4, 3.5 > v2.0.0 is supported in 2.7, 3.4, 3.5 > v2.0.1 is supported in 2.7, 3.4, 3.5 > > cons: under-documents the 'real' support, drops 2.6 without much warning > pros: simple on dev side > > C > v1.5.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 > v2.0.0 is supported in 2.7, 3.4, 3.5 > v2.0.1 is supported in 2.7, 3.4, 3.5 > > cons: muddies the water on 2.0 being 'style only', under documents where > 2.0 will work, implicitly commits us to a 2.6 compatible 1.5.x series but I > do not anticipate us actually doing a 1.5.x series. > > My preference is A > C > B. > > Tom > > On Sun, Sep 27, 2015 at 3:49 PM Thomas Caswell wrote: > >> We already have this 'know to work with' vs 'supported' distinction, this >> is the current state of python 3.2 support. We don't test on it, my >> response to 3.2 specific bugs is 'upgrade', but if we get reasonable, >> non-destructive patches they will get merged (which we have done, around >> the 1.4 release, after we dropped 3.2, we merged some patches >> from Christoph Gohlke which fixed 3.2 on windows). >> >> The reality is that we should have had this discussion 6-12 months ago >> (sorry OceanWolf), instead of on the cusp of a release, and currently >> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with py2.6 >> and py3.3 because we are currently testing on them. There is consensus in >> the core developers that we will not support py2.6/3.3 going forward so the >> question is what to do about the upcoming releases. The options are: >> >> - do not document at all that as far as we know 1.5/2.0 will work on on >> py2.6 >> - document that as far as we know mpl does work on py2.6, but are making >> no commitment to make sure that stays true. >> >> I very much like the second option as it is more accurate and gives _any_ >> support/hope to someone stuck on 2.6. >> >> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which >> back ports bug fixes in a 2.6 compatibly that would be great, otherwise >> given the limited resources the project currently has, that is not >> something we can. >> >> I have already linked to this article is this thread, but once more for >> good measure: >> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html >> >> For reference, debian stable no longer has 2.6 packaged ( >> https://wiki.debian.org/Python/JessieRoadmap) and RHEL has ways of >> getting modern python running on older versions. >> >> And again, as I have said at the bottom of every email, if there is >> someone who really needs new features on 2.6, let me know and we will see >> if we can work something out. >> >> Tom >> >> On Sun, Sep 27, 2015 at 12:31 PM OceanWolf >> wrote: >> >>> On 27/09/15 14:50, Daniele Nicolodi wrote: >>> > I still don't understand what "know to work with" means. From the above >>> > it seems that it means that "you may be luck and we have not break >>> > compatibility, but if we did, then it is on you, we are not going to >>> fix >>> > it". With, to me, reads the same as "not supported". >>> > >>> > Breaking compatibility with python releases in patch version releases >>> is >>> > also a terrible idea, in my opinion. >>> Yes, this underpins the reason for changing to "known to work with...", >>> because we don't want to break compatibility in minor versions, but >>> versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3. >>> > Matplotlib release 1.5 is release candidate now, and as far as I know >>> it >>> > is supposed to work with python 2.6. What changes are you foreseeing in >>> > patch releases of the 1.5 series that will take advantage of breaking >>> > compatibility with python 2.6? >>> > >>> > I believe that matplotlib 1.5 series will be only about bug fixing, and >>> > that all development will go into 2.0. I don't really see how bug fixes >>> > can be helped by dropping compatibility with old python releases. >>> We release 2.0 shortly after 1.5 which means 1.5 won't have any patch >>> fixes, and 2.0 contains no new features, but a change to the default >>> colours. But yes, dropping support for python 2.6 allows us use things >>> such as OrderedDict, not saying we will use such things in 2.0.x >>> (assuming we have a 2.0.x release, fingers crossed we find no bugs), but >>> making the change now to the requirements keeps our options open for the >>> future. >>> >>> Best, >>> OceanWolf >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Mon Sep 28 00:39:47 2015 From: efiring at hawaii.edu (Eric Firing) Date: Sun, 27 Sep 2015 12:39:47 -1000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: <56087033.2030003@hawaii.edu> On 2015/09/27 12:24 PM, Nathaniel Smith wrote: > and IMHO the simplest way to communicate that policy to users is to just > say for both the 1.5.0 and 2.0.0: > > Supported versions: 2.7, 3.4, 3.5 > Other versions (esp. 2.6 and 3.3) might also work, but this is at your > own risk. > I agree, and prefer this over the alternatives. Eric From daniele at grinta.net Mon Sep 28 10:31:44 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 28 Sep 2015 10:31:44 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <56081949.9060203@yahoo.co.uk> References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: <5608FAF0.1070708@grinta.net> On 27/09/15 18:28, OceanWolf wrote: > On 27/09/15 14:50, Daniele Nicolodi wrote: >> I still don't understand what "know to work with" means. From the above >> it seems that it means that "you may be luck and we have not break >> compatibility, but if we did, then it is on you, we are not going to fix >> it". With, to me, reads the same as "not supported". >> >> Breaking compatibility with python releases in patch version releases is >> also a terrible idea, in my opinion. > > Yes, this underpins the reason for changing to "known to work with...", > because we don't want to break compatibility in minor versions, but > versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3. So why not state that 1.5 and 2.0 are supported on python 2.6 and 3.3? I'm missing the point in phasing out support without a reason. It is well tested, it works, we are not planning to introduce new functionality, but yet we want to drop support for old python versions. Why? I fear that the the urge of doing so is driven almost exclusively by some guy or another writing a blog post stating that this is what projects should do. >> Matplotlib release 1.5 is release candidate now, and as far as I know it >> is supposed to work with python 2.6. What changes are you foreseeing in >> patch releases of the 1.5 series that will take advantage of breaking >> compatibility with python 2.6? >> >> I believe that matplotlib 1.5 series will be only about bug fixing, and >> that all development will go into 2.0. I don't really see how bug fixes >> can be helped by dropping compatibility with old python releases. > > We release 2.0 shortly after 1.5 which means 1.5 won't have any patch > fixes, and 2.0 contains no new features, but a change to the default > colours. But yes, dropping support for python 2.6 allows us use things > such as OrderedDict, not saying we will use such things in 2.0.x > (assuming we have a 2.0.x release, fingers crossed we find no bugs), but > making the change now to the requirements keeps our options open for the > future. I think that there is some misunderstanding. Thomas is proposing to drop support for python versions in patch level release 2.0.1. My understanding of a patch level release is that it only fixes bugs, and for fixing bugs we don't need to drop support for old python version or use newer python versions features. If you want to add features, call it 2.1 or something. Cheers, Daniele From daniele at grinta.net Mon Sep 28 10:51:22 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 28 Sep 2015 10:51:22 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: <5608FF8A.6070902@grinta.net> On 27/09/15 21:49, Thomas Caswell wrote: > We already have this 'know to work with' vs 'supported' distinction, > this is the current state of python 3.2 support. We don't test on it, > my response to 3.2 specific bugs is 'upgrade', but if we get reasonable, > non-destructive patches they will get merged (which we have done, around > the 1.4 release, after we dropped 3.2, we merged some patches > from Christoph Gohlke which fixed 3.2 on windows). > > The reality is that we should have had this discussion 6-12 months ago > (sorry OceanWolf), instead of on the cusp of a release, and currently > master (and hence both the 1.5.0 and 2.0 releases) _will_ work with > py2.6 and py3.3 because we are currently testing on them. There is > consensus in the core developers that we will not support py2.6/3.3 > going forward so the question is what to do about the upcoming > releases. I agree that this discussion would have been better when the 1.5 and 2.0 releases were planned, but I don't see much of a problem in defining things now, as not disruptive changes have been made to the codebase. I agree that dropping support for python 2.6 and 3.3 is the way to go. What I'm objecting is the "labeling" you are suggesting both in the sense of the "supported" vs "known to work with" terminology and with release numbers. As Nathaniel pointed out it does not make much sense to drop support for python 2.6 and 3.3 in a micro/patch level release. I think it makes much more sense to plan to have a 2.1 release after 2.0 in which new features could be added and old python versions support removed. Then 2.0 becomes a bugfix only branch. I haven't looked at the code, but I believe that the only difference between 1.5 and 2.0 are the style defaults, so, if there is demand, I don't see a problem to also backport bugfixes to the 1.5 branch and release 1.5 series bugfixes. > The options are: > > - do not document at all that as far as we know 1.5/2.0 will work on on > py2.6 > - document that as far as we know mpl does work on py2.6, but are > making no commitment to make sure that stays true. There is another option: - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop support on 2.1 where new development that can benefit from new python features should happen > Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which > back ports bug fixes in a 2.6 compatibly that would be great, otherwise > given the limited resources the project currently has, that is not > something we can. I can try to contribute a bit, but, as I was trying to explain above, I'm not opposing to drop support for old python releases, but merely to the labeling and wording. > I have already linked to this article is this thread, but once more for > good measure: > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html As the work to make 1.5 and 2.0 releases work with python 2.6 and 3.3 has already been done, I don't think this article is much relevant to the discussion. I'm all in favor of not keeping python 2.6 support, and I don't think that anyone that uses python 3 is stuck with an old python 3.3. But given that we already have the support for those release, please keep it and drop it in a future release. Cheer, Daniele From efiring at hawaii.edu Mon Sep 28 10:52:23 2015 From: efiring at hawaii.edu (Eric Firing) Date: Sun, 27 Sep 2015 22:52:23 -1000 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <5608FAF0.1070708@grinta.net> References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> <5608FAF0.1070708@grinta.net> Message-ID: <5608FFC7.70506@hawaii.edu> On 2015/09/27 10:31 PM, Daniele Nicolodi wrote: > So why not state that 1.5 and 2.0 are supported on python 2.6 and 3.3? > > I'm missing the point in phasing out support without a reason. It is > well tested, it works, we are not planning to introduce new > functionality, but yet we want to drop support for old python versions. > Why? I fear that the the urge of doing so is driven almost exclusively > by some guy or another writing a blog post stating that this is what > projects should do. For 1.5 it wouldn't matter much. With luck, there won't be anything beyond 1.5.0. For 2.0 it would, because from there we will be trying to move forward. It is easier to do that without having to maintain backwards compatibility with old pythons. Eric From daniele at grinta.net Mon Sep 28 11:02:59 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 28 Sep 2015 11:02:59 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> Message-ID: <56090243.8010802@grinta.net> On 27/09/15 21:58, Thomas Caswell wrote: > To follow up the following is the matrix of possible 'supported python' > tables for the next few releases: Unfortunately, this is only a partial matrix, and as Nathaniel pointed out is not self-consistent: supported means that we fix bugs and release patched version, if the patched version does not maintain compatibility promises we are breaking support. > A > > v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, > and 3.3 > v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3 > > cons: 'known to work with' is controversial/confusing, may pick up > incompatibilities on a micro release. > pros: simple on dev side, lets 2.6/3.3 semi-gracefully fall away. > > B > v1.5.0 is supported in 2.7, 3.4, 3.5 > v2.0.0 is supported in 2.7, 3.4, 3.5 > v2.0.1 is supported in 2.7, 3.4, 3.5 > > cons: under-documents the 'real' support, drops 2.6 without much warning > pros: simple on dev side > > C > v1.5.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 > v2.0.0 is supported in 2.7, 3.4, 3.5 > v2.0.1 is supported in 2.7, 3.4, 3.5 > > cons: muddies the water on 2.0 being 'style only', under documents where > 2.0 will work, implicitly commits us to a 2.6 compatible 1.5.x series > but I do not anticipate us actually doing a 1.5.x series. > > My preference is A > C > B. Usually people votes on alternative proposals once all the different options are laid down and agreed upon. I would like to add: D v1.5 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 (status quo) v2.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 (status quo) v2.1 is supported in 2.7, 3.4, 3.5 This is with the assumption that v1.5.x bugfix releases happen only if mayor bugs that make it unusable are found in 1.5, and v2.0.x bugfix releases happen until 2.1 is released. 2.0 differs from 1.5 only for the default styles, that (I believe) can be set to the 1.5 ones via configuration parameters, thus the ones that require extended support for the 1.5 series can simply grab the 2.0.x releases and modify the default settings. pros: keeps promises, easy to communicate and understand cons: one bugfix only branch needs to be maintained Cheers, Daniele From thomas.robitaille at gmail.com Mon Sep 28 13:58:51 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 28 Sep 2015 13:58:51 +0200 Subject: [Matplotlib-devel] supported python versions In-Reply-To: <5608FF8A.6070902@grinta.net> References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> <5608FF8A.6070902@grinta.net> Message-ID: If Python 2.6 and 3.3 support is completely dropped in Matplotlib 1.5 and 2.0, I don't think you will hear (m)any complaints from users. When I did a survey earlier this year, only 2% of users were on Python 2.6 and 1% on 3.3: http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/ >From an external point of view (since I am not a Matplotlib core dev), I personally think option C makes more sense, i.e. still officially supporting 2.6 and 3.3 in 1.5 (all the hard work is done) and then dropping support in 2.0. Cheers, Tom Daniele Nicolodi wrote: > On 27/09/15 21:49, Thomas Caswell wrote: >> We already have this 'know to work with' vs 'supported' distinction, >> this is the current state of python 3.2 support. We don't test on it, >> my response to 3.2 specific bugs is 'upgrade', but if we get reasonable, >> non-destructive patches they will get merged (which we have done, around >> the 1.4 release, after we dropped 3.2, we merged some patches >> from Christoph Gohlke which fixed 3.2 on windows). >> >> The reality is that we should have had this discussion 6-12 months ago >> (sorry OceanWolf), instead of on the cusp of a release, and currently >> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with >> py2.6 and py3.3 because we are currently testing on them. There is >> consensus in the core developers that we will not support py2.6/3.3 >> going forward so the question is what to do about the upcoming >> releases. > I agree that this discussion would have been better when the 1.5 and 2.0 > releases were planned, but I don't see much of a problem in defining > things now, as not disruptive changes have been made to the codebase. > > I agree that dropping support for python 2.6 and 3.3 is the way to go. > What I'm objecting is the "labeling" you are suggesting both in the > sense of the "supported" vs "known to work with" terminology and with > release numbers. > > As Nathaniel pointed out it does not make much sense to drop support for > python 2.6 and 3.3 in a micro/patch level release. I think it makes much > more sense to plan to have a 2.1 release after 2.0 in which new features > could be added and old python versions support removed. Then 2.0 becomes > a bugfix only branch. I haven't looked at the code, but I believe that > the only difference between 1.5 and 2.0 are the style defaults, so, if > there is demand, I don't see a problem to also backport bugfixes to the > 1.5 branch and release 1.5 series bugfixes. > >> The options are: >> >> - do not document at all that as far as we know 1.5/2.0 will work on on >> py2.6 >> - document that as far as we know mpl does work on py2.6, but are >> making no commitment to make sure that stays true. > There is another option: > > - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop support on > 2.1 where new development that can benefit from new python features > should happen > >> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which >> back ports bug fixes in a 2.6 compatibly that would be great, otherwise >> given the limited resources the project currently has, that is not >> something we can. > I can try to contribute a bit, but, as I was trying to explain above, > I'm not opposing to drop support for old python releases, but merely to > the labeling and wording. > >> I have already linked to this article is this thread, but once more for >> good measure: >> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > As the work to make 1.5 and 2.0 releases work with python 2.6 and 3.3 > has already been done, I don't think this article is much relevant to > the discussion. I'm all in favor of not keeping python 2.6 support, and > I don't think that anyone that uses python 3 is stuck with an old python > 3.3. But given that we already have the support for those release, > please keep it and drop it in a future release. > > Cheer, > Daniele > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From ben.v.root at gmail.com Mon Sep 28 15:28:38 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 28 Sep 2015 09:28:38 -0400 Subject: [Matplotlib-devel] supported python versions In-Reply-To: References: <55F7FC90.40500@grinta.net> <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk> <5608FF8A.6070902@grinta.net> Message-ID: I am for either C or D. It makes zero sense to me to drop 2.6/3.3 on a bugfix release, which is why I thought that v2.0.1 was a typo earlier. Ben Root On Mon, Sep 28, 2015 at 7:58 AM, Thomas Robitaille < thomas.robitaille at gmail.com> wrote: > If Python 2.6 and 3.3 support is completely dropped in Matplotlib 1.5 > and 2.0, I don't think you will hear (m)any complaints from users. When > I did a survey earlier this year, only 2% of users were on Python 2.6 > and 1% on 3.3: > > http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/ > > From an external point of view (since I am not a Matplotlib core dev), > I personally think option C makes more sense, i.e. still officially > supporting 2.6 and 3.3 in 1.5 (all the hard work is done) and then > dropping support in 2.0. > > Cheers, > Tom > > Daniele Nicolodi wrote: > > On 27/09/15 21:49, Thomas Caswell wrote: > >> We already have this 'know to work with' vs 'supported' distinction, > >> this is the current state of python 3.2 support. We don't test on it, > >> my response to 3.2 specific bugs is 'upgrade', but if we get reasonable, > >> non-destructive patches they will get merged (which we have done, around > >> the 1.4 release, after we dropped 3.2, we merged some patches > >> from Christoph Gohlke which fixed 3.2 on windows). > >> > >> The reality is that we should have had this discussion 6-12 months ago > >> (sorry OceanWolf), instead of on the cusp of a release, and currently > >> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with > >> py2.6 and py3.3 because we are currently testing on them. There is > >> consensus in the core developers that we will not support py2.6/3.3 > >> going forward so the question is what to do about the upcoming > >> releases. > > I agree that this discussion would have been better when the 1.5 and 2.0 > > releases were planned, but I don't see much of a problem in defining > > things now, as not disruptive changes have been made to the codebase. > > > > I agree that dropping support for python 2.6 and 3.3 is the way to go. > > What I'm objecting is the "labeling" you are suggesting both in the > > sense of the "supported" vs "known to work with" terminology and with > > release numbers. > > > > As Nathaniel pointed out it does not make much sense to drop support for > > python 2.6 and 3.3 in a micro/patch level release. I think it makes much > > more sense to plan to have a 2.1 release after 2.0 in which new features > > could be added and old python versions support removed. Then 2.0 becomes > > a bugfix only branch. I haven't looked at the code, but I believe that > > the only difference between 1.5 and 2.0 are the style defaults, so, if > > there is demand, I don't see a problem to also backport bugfixes to the > > 1.5 branch and release 1.5 series bugfixes. > > > >> The options are: > >> > >> - do not document at all that as far as we know 1.5/2.0 will work on on > >> py2.6 > >> - document that as far as we know mpl does work on py2.6, but are > >> making no commitment to make sure that stays true. > > There is another option: > > > > - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop support on > > 2.1 where new development that can benefit from new python features > > should happen > > > >> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which > >> back ports bug fixes in a 2.6 compatibly that would be great, otherwise > >> given the limited resources the project currently has, that is not > >> something we can. > > I can try to contribute a bit, but, as I was trying to explain above, > > I'm not opposing to drop support for old python releases, but merely to > > the labeling and wording. > > > >> I have already linked to this article is this thread, but once more for > >> good measure: > >> > http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html > > As the work to make 1.5 and 2.0 releases work with python 2.6 and 3.3 > > has already been done, I don't think this article is much relevant to > > the discussion. I'm all in favor of not keeping python 2.6 support, and > > I don't think that anyone that uses python 3 is stuck with an old python > > 3.3. But given that we already have the support for those release, > > please keep it and drop it in a future release. > > > > Cheer, > > Daniele > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Tue Sep 29 15:38:33 2015 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 29 Sep 2015 09:38:33 -0400 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: References: <56048B26.7060903@yahoo.co.uk> Message-ID: <560A9459.80406@stsci.edu> I think it's a great idea to look carefully at branding as a whole, and not take any changes lightly. Thanks for getting that ball rolling, Thomas. One thing that occurred to me today, as I walked into the Javits Center and saw the matplotlib logo reproduced about 5 feet wide on a banner hanging above the expo hall, is that we have a lot of inertia in the current design, and we shouldn't take any change lightly. As much as we are moving to a better color map, the colors in the logo (and the orange especially )are a strong part of the branding and branding in Scipy projects in general. Mike On 09/24/2015 10:43 PM, Thomas Caswell wrote: > I think any redesign of the logo should go together with a wider > ranging overhaul of the website, it's information architecture, and > our visual identity. To that end I have enlisted a professional web > developer/designer to help us (disclosure, my fiancee). There > probably won't be much work done in that direction until after our > wedding next month. > > I like the idea, but am hesitant to make any changes in isolation. > > Tom > > On Thu, Sep 24, 2015 at 8:54 PM Benjamin Root > wrote: > > I am not against changing the logo, but if we do so, then it > should be a much more significant change. I actually like the jet > version of the logo better because of the wide variety of colors. > Uniform perception isn't a needed trait for graphs like those. > > On Sep 24, 2015 8:17 PM, "OceanWolf" > > wrote: > > Looking at the current logo, I wondered whether we would want > to change this as part of the style changes when we release > 2.0... as well as marketing our new style, the current logo > uses jet to make the graph... > > Playing around with the examples/api/logo2.py I found changing > line 68 to: > > bar.set_facecolor(cm.viridis(r/8.)) > > gave pleasing results with the largest wedge getting coloured > green (see attached for uncropped version). > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue Sep 29 20:31:34 2015 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 29 Sep 2015 08:31:34 -1000 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: <560A9459.80406@stsci.edu> References: <56048B26.7060903@yahoo.co.uk> <560A9459.80406@stsci.edu> Message-ID: <560AD906.9060709@hawaii.edu> On 2015/09/29 3:38 AM, Michael Droettboom wrote: > matplotlib logo reproduced about 5 feet wide on a banner hanging above > the expo hall I hope it is OK to fix the Navier-Stokes equation, though. It won't change the general appearance, but it will save some embarrassment. (I have no idea what the rest of the math in the logo is, but the botched N-S equation is prominent.) Eric From Nicolas.Rougier at inria.fr Tue Sep 29 21:06:09 2015 From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier) Date: Tue, 29 Sep 2015 21:06:09 +0200 Subject: [Matplotlib-devel] MPL2 Logo In-Reply-To: <560AD906.9060709@hawaii.edu> References: <56048B26.7060903@yahoo.co.uk> <560A9459.80406@stsci.edu> <560AD906.9060709@hawaii.edu> Message-ID: <61BC32FF-909B-4CC5-9976-695962652B58@inria.fr> Just my two cents but the unusual size of the logo makes it difficult to integrate at various places. I've made a cover for the scipy lecture notes (hidden advertisement, see http://www.scipy-lectures.org) and I was unable to properly integrate it. In the end, I chose to make a brand new one (see below). I'm not saying this new one is better, but it would be good to have a more "square" version of the current logo. Nicolas Scipy lecture notes cover: https://github.com/scipy-lectures/scipy-lecture-notes/blob/master/images/cover-v2.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: matplotlib.pdf Type: application/pdf Size: 2047 bytes Desc: not available URL: -------------- next part -------------- > On 29 Sep 2015, at 20:31, Eric Firing wrote: > > On 2015/09/29 3:38 AM, Michael Droettboom wrote: >> matplotlib logo reproduced about 5 feet wide on a banner hanging above >> the expo hall > > I hope it is OK to fix the Navier-Stokes equation, though. It won't change the general appearance, but it will save some embarrassment. (I have no idea what the rest of the math in the logo is, but the botched N-S equation is prominent.) > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From penugondasrinath at gmail.com Fri Sep 25 21:19:25 2015 From: penugondasrinath at gmail.com (programmer86) Date: Fri, 25 Sep 2015 12:19:25 -0700 (MST) Subject: [Matplotlib-devel] [Error 17]No usable Temporary file name found. Message-ID: <1443208765933-46219.post@n5.nabble.com> Hi, I developed a tool in Python 2.7.8 and packaged it using "py2exe". When I run the tool I get the following error Traceback (most recent call last): File "application_gui.py", line 2, in File "modules\Application.pyc", line 13, in File "modules\Base.pyc", line 15, in File "matplotlib\__init__.pyc", line 764, in File "matplotlib\__init__.pyc", line 682, in rc_params File "matplotlib\__init__.pyc", line 595, in matplotlib_fname File "matplotlib\__init__.pyc", line 248, in wrapper File "matplotlib\__init__.pyc", line 470, in _get_configdir File "matplotlib\__init__.pyc", line 176, in _is_writable_dir File "tempfile.pyc", line 462, in NamedTemporaryFile File "tempfile.pyc", line 251, in _mkstemp_inner IOError: [Errno 17] No usable temporary file name found I am using matplotlib 1.4.3. Thanks, Srinath. -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Error-17-No-usable-Temporary-file-name-found-tp46219.html Sent from the matplotlib - devel mailing list archive at Nabble.com.