matplotlib-devel Mailing List for matplotlib (Page 2)

Nicolas
I get that too, (with your script and various things in my work).
But if you zoom in, the lines are in the right place. Is it
some kind of screen aliasing?
Jules

Hi,
I tried to plot a grid over a small image (24x24) and some grid lines are mis-aligned, can anybody confirm the behavior ?
Here is a sample script:
import numpy as np
import matplotlib.pyplot as plt
n = 16
fig = plt.figure(figsize=(10,10))
Z = np.array(([0,1]*(n//2) + [1,0]*(n//2))*(n//2)).reshape(n,n)
plt.imshow(Z, interpolation='nearest', cmap=plt.cm.gray, extent=[0,n,0,n], alpha=.25)
plt.xticks(np.arange(0,n), [])
plt.yticks(np.arange(0,n), [])
plt.grid(ls='solid')
plt.show()
Here is a sample output (it's worse on screen):
Nicolas

On Mon, Oct 29, 2012 at 9:16 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Mon, Oct 29, 2012 at 1:51 AM, Patrick Marsh <pat...@gm...>wrote:
>
>> Greetings,
>>
>> I've banged my head against this problem for 2 days and have given up on
>> figuring it out on my own...
>>
>> After updating numpy and matplotlib to the latest versions from github
>> Saturday morning, I keep getting "AttributeError: incompatible shape for a
>> non-contiguous array" errors all over the place when plotting. When I run
>> tests on numpy, everything passes. When I run tests on matplotlib, I get 51
>> errors, with a vast majority of them (possibly all) being the
>> non-contiguous array errors. (Sample below)
>>
>> Any suggestions here? I'm totally stumped.
>>
>>
>> PTM
>>
>>
>>
> I am guessing this is a problem introduced with NumPy. I just tried the
> tests with an older NumPy branch, and all seemed fine. Now testing with
> the most recent branch.
>
> Ben Root
>
Confirming the bug (and it appears to be happening at a spot that I updated
a couple years ago to catch exactly these sort of situations where
reshaping would result in a copy when we didn't want a copy).
I am presuming that it is a NumPy bug and will report it as such to the
numpy list.
Cheers!
Ben Root

On Mon, Oct 29, 2012 at 1:51 AM, Patrick Marsh <pat...@gm...>wrote:
> Greetings,
>
> I've banged my head against this problem for 2 days and have given up on
> figuring it out on my own...
>
> After updating numpy and matplotlib to the latest versions from github
> Saturday morning, I keep getting "AttributeError: incompatible shape for a
> non-contiguous array" errors all over the place when plotting. When I run
> tests on numpy, everything passes. When I run tests on matplotlib, I get 51
> errors, with a vast majority of them (possibly all) being the
> non-contiguous array errors. (Sample below)
>
> Any suggestions here? I'm totally stumped.
>
>
> PTM
>
>
>
I am guessing this is a problem introduced with NumPy. I just tried the
tests with an older NumPy branch, and all seemed fine. Now testing with
the most recent branch.
Ben Root

Hi Geoffroy
This will certainly be very useful. I need to spend some time looking at
it and seeing how it would best fit within the matplotlib framework,
particularly as only a few days ago I committed to writing a triangular
grid interpolator for quad grids and it would be sensible to group these
interpolators together in some way.
I'll get back to you when I've had time to look at it.
Thanks for your efforts!
Ian
On 28 October 2012 20:17, GBillotey <geo...@gm...> wrote:
> Hi!
>
>
> I had recently to develop interpolators for a function defined at the nodes
> of a user-specified triangular mesh.
> (Beside interpolation, it can help producing higher-quality tricontour
> plots, using interpolation on a refined mesh and matplotlib tricontour
> function.)
>
> Being a regular user of matplotlib, I would be happy if it can be useful to
> others...
> The code is hosted here:
> https://github.com/GBillotey/trimesh-interpolator.git
>
>
> Please let me know if it this dev. can be useful and if the code needs some
> cleaning (I am not a computer scientist, only a mechanical engineer)
>
>
> Cheers,
> Geoffroy.
>

Greetings,
I've banged my head against this problem for 2 days and have given up on
figuring it out on my own...
After updating numpy and matplotlib to the latest versions from github
Saturday morning, I keep getting "AttributeError: incompatible shape for a
non-contiguous array" errors all over the place when plotting. When I run
tests on numpy, everything passes. When I run tests on matplotlib, I get 51
errors, with a vast majority of them (possibly all) being the
non-contiguous array errors. (Sample below)
Any suggestions here? I'm totally stumped.
PTM
----------------------------------------------------------------------
Traceback (most recent call last):
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/nose-1.2.1-py2.7.egg/nose/case.py",
line 197, in runTest
 self.test(*self.arg)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 39, in failer
 result = f(*args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 145, in do_test
 figure.savefig(actual_fname)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/figure.py",
line 1363, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/backend_bases.py",
line 2118, in print_figure
 **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/backend_bases.py",
line 1894, in print_svg
 return svg.print_svg(*args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/backends/backend_svg.py",
line 1103, in print_svg
 return self._print_svg(filename, svgwriter, fh_to_close, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/backends/backend_svg.py",
line 1139, in _print_svg
 self.figure.draw(renderer)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/artist.py",
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/figure.py",
line 999, in draw
 func(*args)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/artist.py",
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/axes.py",
line 2086, in draw
 a.draw(renderer)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/artist.py",
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/collections.py",
line 699, in draw
 return Collection.draw(self, renderer)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/artist.py",
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/collections.py",
line 248, in draw
 transform, transOffset, offsets, paths = self._prepare_points()
 File
"/home/Patrick.Marsh/.local/lib/python2.7/site-packages/matplotlib/collections.py",
line 222, in _prepare_points
 offsets.shape = (-1, 2) # Make it Nx2
AttributeError: incompatible shape for a non-contiguous array
----------------------------------------------------------------------
Ran 1123 tests in 401.586s
FAILED (KNOWNFAIL=282, SKIP=3, errors=51)
---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
National Severe Storms Laboratory
http://www.patricktmarsh.com

 Hi!
I had recently to develop interpolators for a function defined at the nodes
of a user-specified triangular mesh.
(Beside interpolation, it can help producing higher-quality tricontour
plots, using interpolation on a refined mesh and matplotlib tricontour
function.)
Being a regular user of matplotlib, I would be happy if it can be useful to
others...
The code is hosted here:
https://github.com/GBillotey/trimesh-interpolator.git
Please let me know if it this dev. can be useful and if the code needs some
cleaning (I am not a computer scientist, only a mechanical engineer)
Cheers,
Geoffroy.
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Interpolation-in-a-triangular-mesh-tri-Triangulation-tp39586.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Thanks. That would be much appreciated.
Mike
On 10/23/2012 05:10 PM, Thomas Kluyver wrote:
> I've just noticed that matplotlib on PyPI doesn't have any trove
> classifiers. I think it would be good to add these for the 1.2 release
> - apart from anything else, it will indicate to the various automated
> tools checking Python 3 compatibility that matplotlib is now
> compatible.
>
> Here are the classifiers I think are relevant:
>
> Development Status :: 5 - Production/Stable
> Intended Audience :: Science/Research (not exclusively, of course -
> thoughts on using this?)
> License :: OSI Approved :: Python Software Foundation License (the
> website says it is 'based on' the PSF license - is it close enough?)
> Programming Language :: Python
> Programming Language :: Python :: 2
> Programming Language :: Python :: 3
> Topic :: Scientific/Engineering :: Visualization
>
> If that seems reasonable, I'm happy to put them into a pull request
> against 1.2.x.
>
> Thanks,
> Thomas
>
> P.S. Apologies if this comes through twice - I posted from the wrong
> e-mail address the first time.
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I've just noticed that matplotlib on PyPI doesn't have any trove
classifiers. I think it would be good to add these for the 1.2 release
- apart from anything else, it will indicate to the various automated
tools checking Python 3 compatibility that matplotlib is now
compatible.
Here are the classifiers I think are relevant:
Development Status :: 5 - Production/Stable
Intended Audience :: Science/Research (not exclusively, of course -
thoughts on using this?)
License :: OSI Approved :: Python Software Foundation License (the
website says it is 'based on' the PSF license - is it close enough?)
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 3
Topic :: Scientific/Engineering :: Visualization
If that seems reasonable, I'm happy to put them into a pull request
against 1.2.x.
Thanks,
Thomas
P.S. Apologies if this comes through twice - I posted from the wrong
e-mail address the first time.

I rebased #1418 on v1.2.x as #1425 as suggested by Damon McDougall. It
turns out that the other bug #1419 is only present on master and
introduced in a resent pep8 rewrite not merged into v1.2.x
Cheers,
Jens
---------- Forwarded message ----------
From: Mark Lawrence <bre...@ya...>
Date: Mon, Oct 22, 2012 at 6:53 PM
Subject: Re: [matplotlib-devel] Cutting 1.2rc3
To: mat...@li...
On 22/10/2012 15:10, Michael Droettboom wrote:
> Thanks to everyone for the hard work on getting the last few bugs
> squashed! I think 1.2.0 is going to be a very high quality release. It
> looks like we're only down to one last issue marked for 1.2.
>
> https://github.com/matplotlib/matplotlib/pull/1326
> <https://github.com/matplotlib/matplotlib/pull/1326/files>
>
> Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this
> will be the last release candidate for 1.2.0 and we won't need to make
> any significant additions before the final release.
>
> Then we can all move forward with the good number of PEP8 fixes, larger
> MEP improvements and other great features in the pipeline.
>
> Mike
>
Oh mammary glands I'd intended to do some testing on Windows for you
guys and it's gone completely under my radar, sorry about that.
I can still give it a try though. I've got 2.7.3 and 3.3.0 on my PC but
I don't want to repeat what someone else may have done already. What's
the best way forward?
--
Cheers.
Mark Lawrence.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 22/10/2012 15:10, Michael Droettboom wrote:
> Thanks to everyone for the hard work on getting the last few bugs
> squashed! I think 1.2.0 is going to be a very high quality release. It
> looks like we're only down to one last issue marked for 1.2.
>
> https://github.com/matplotlib/matplotlib/pull/1326
> <https://github.com/matplotlib/matplotlib/pull/1326/files>
>
> Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this
> will be the last release candidate for 1.2.0 and we won't need to make
> any significant additions before the final release.
>
> Then we can all move forward with the good number of PEP8 fixes, larger
> MEP improvements and other great features in the pipeline.
>
> Mike
>
Oh mammary glands I'd intended to do some testing on Windows for you 
guys and it's gone completely under my radar, sorry about that.
I can still give it a try though. I've got 2.7.3 and 3.3.0 on my PC but 
I don't want to repeat what someone else may have done already. What's 
the best way forward?
-- 
Cheers.
Mark Lawrence.

On Monday, October 22, 2012, Benjamin Root wrote:
>
>
> On Mon, Oct 22, 2012 at 10:10 AM, Michael Droettboom <md...@st...<javascript:_e({}, 'cvml', 'md...@st...');>
> > wrote:
>
>> Thanks to everyone for the hard work on getting the last few bugs
>> squashed! I think 1.2.0 is going to be a very high quality release. It
>> looks like we're only down to one last issue marked for 1.2.
>>
>> https://github.com/matplotlib/matplotlib/pull/1326<https://github.com/matplotlib/matplotlib/pull/1326/files>
>>
>> Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this
>> will be the last release candidate for 1.2.0 and we won't need to make any
>> significant additions before the final release.
>>
>> Then we can all move forward with the good number of PEP8 fixes, larger
>> MEP improvements and other great features in the pipeline.
>>
>> Mike
>>
>>
> That should be do-able. I think all we really need for that PR is the
> addition of documentation describing what does a transform of None means.
>
Phil expressed some concerns regarding similar transform problems with
Collections. I don't think these have been addressed yet.
There have also been a few bug fixes that have popped up in the last few
days. Jens Nielsen has a couple of bounding box tweaks to make tables work
with bbox_inches='tight'. There was also another issue opened regarding the
parsing of the edgecolors kwarg in ax.pcolor.
Jens' pull request is a bug fix, in my opinion. It is currently targeted
for master (as is the currently milestoned 1.2 PR regarding transforms) but
I don't see any reason for it to not make 1.2. If others feel the same then
I would rather see it targeted properly as opposed to it being
cherry-picked.
> Cheers!
> Ben Root
>
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Mon, Oct 22, 2012 at 10:10 AM, Michael Droettboom <md...@st...>wrote:
> Thanks to everyone for the hard work on getting the last few bugs
> squashed! I think 1.2.0 is going to be a very high quality release. It
> looks like we're only down to one last issue marked for 1.2.
>
> https://github.com/matplotlib/matplotlib/pull/1326<https://github.com/matplotlib/matplotlib/pull/1326/files>
>
> Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this
> will be the last release candidate for 1.2.0 and we won't need to make any
> significant additions before the final release.
>
> Then we can all move forward with the good number of PEP8 fixes, larger
> MEP improvements and other great features in the pipeline.
>
> Mike
>
>
That should be do-able. I think all we really need for that PR is the
addition of documentation describing what does a transform of None means.
Cheers!
Ben Root

Sorry to be late to this -- it does seem to be working for me now. Can 
you confirm it's also working for you?
Mike
On 10/19/2012 05:08 PM, Joe Kington wrote:
> Github has been under a DDOS for the past couple of days: 
> https://status.github.com/
>
> It's probably(?) related, but lots of other github pages sites seem to 
> be up...
>
> On Fri, Oct 19, 2012 at 3:54 PM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
> Not just you, I can't get on either. I noticed this about an hour
> ago, too.
>
> Ben
>
>
> On Fri, Oct 19, 2012 at 4:34 PM, Damon McDougall
> <dam...@gm... <mailto:dam...@gm...>> wrote:
>
> Is it just me or is our github pages server down?
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Thanks to everyone for the hard work on getting the last few bugs 
squashed! I think 1.2.0 is going to be a very high quality release. It 
looks like we're only down to one last issue marked for 1.2.
https://github.com/matplotlib/matplotlib/pull/1326 
<https://github.com/matplotlib/matplotlib/pull/1326/files>
Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this 
will be the last release candidate for 1.2.0 and we won't need to make 
any significant additions before the final release.
Then we can all move forward with the good number of PEP8 fixes, larger 
MEP improvements and other great features in the pipeline.
Mike

All,
Several days ago I tested the waters and asked you guys, the
community, how useful you thought a command-line front-end to
matplotlib would be. The overwhelmingly positive feedback was enough
for me to sit down and figure out how to do this well, and in a way
that would mimic existing tools to achieve such tasks. One example
being the `graph` utility, which is a part of GNU plotutils. Though
there are subtle differences between mpl_binutils and GNU plotutils
they, in my opinion, improve the user experience and reduce the
ambiguity regarding the parsing of command-line options.
I am announcing that mpl_binutils is in a state ready to be tested by
you guys. Hopefully you'll find it useful. You can check out the
source code here: https://github.com/dmcdougall/mpl_binutils
Without getting into details, I ran into some serious limitations with
argparse. At the end of the day, nothing is perfect, but some tools
are better than others. One such tool, docopt, was shown to me by Mark
Lawrence. docopt will change the way I do any python from the
command-line in the future. docopt is a light-weight command-line
parsing library written in python with no dependencies.
mpl_binutils has two dependencies: docopt and matplotlib. Most of you
should already have one of these! For the other, a simple `pip install
docopt` should work but I had no problems installing it from source
(python setup.py install) on OS X. mpl_binutils is currently a single
script (a python script), called mpl-graph. There is example usage on
the github readme if you'd like to take a look.
Currently, mpl-graph doesn't fail gracefully. It should, but I wanted
to get something working first. Command-line option validation is next
on my todo list and since there are only a handful of command line
options implemented (albeit the most useful ones, in my opinion), this
shouldn't be too big of a job.
Go forth and fork!
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Github has been under a DDOS for the past couple of days:
https://status.github.com/
It's probably(?) related, but lots of other github pages sites seem to be
up...
On Fri, Oct 19, 2012 at 3:54 PM, Benjamin Root <ben...@ou...> wrote:
> Not just you, I can't get on either. I noticed this about an hour ago,
> too.
>
> Ben
>
>
> On Fri, Oct 19, 2012 at 4:34 PM, Damon McDougall <
> dam...@gm...> wrote:
>
>> Is it just me or is our github pages server down?
>>
>> --
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> B2.39
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> West Midlands
>> CV4 7AL
>> United Kingdom
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Not just you, I can't get on either. I noticed this about an hour ago, too.
Ben
On Fri, Oct 19, 2012 at 4:34 PM, Damon McDougall
<dam...@gm...>wrote:
> Is it just me or is our github pages server down?
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Is it just me or is our github pages server down?
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Tue, Oct 16, 2012 at 6:36 PM, T J <tj...@gm...> wrote:
> There seems to be an issue with how arguments are parsed when it comes
> to determining the color of a line. Generally, it seems that 'c'
> takes precedence over 'color'. However, this precedence seems to
> change with the number of passed kwargs.
>
>
Yeah, there is a bit of a can of worms here. I suspect that part of the
issue has to do with dictionaries not guaranteeing order, but I can't
figure out where that would happen, though. In the plot handling code, we
are explicitly looking for the "color" kwarg, never the 'c' kwarg. It is
over in the Line2D class that the "c" kwarg ever gets obtained. In that
situation, what is likely happening is that the plot() code creates the
Line2D object, passing the "color" kwarg that it extracted, and any other
kwargs to the Line2D constructor (such as the 'c' kwarg). My guess is that
the whole aliasing system is rather ad-hoc, and actually doesn't have
explicit precedence because it was never intended for both kwargs to appear
at the same time.
Could you file an issue on the github tracker about this?
Thank you,
Ben Root

Thanks for your comments! see below...
On 10/16/2012 10:14 AM, Damon McDougall wrote:
> On Tue, Oct 16, 2012 at 2:55 PM, Kevin Davies <kda...@gm...> wrote:
>> Hello,
>>
>> I made a few minor changes to the Sankey class. They are listed at:
>> https://github.com/kdavies4/matplotlib/compare/master...sankey5
>>
>> Please review this and let me know if I can submit a pull request.
>>
>> Thanks.
>>
>> Kevin
> Thanks for taking the time to fix up a part of the codebase!
>
> If you make a pull request out of your code, we'll be able to leave
> inline comments on your patches. Nonetheless, I have some feedback for
> you after a (very) quick glance:
I submitted the pull request.
> 1) I don't think 'orientations' is a python keyword. What is the error
> you were getting? In any case, changing it breaks backwards
> compatibility so I'd be an advocate of keeping 'orientations'. Unless,
> of course, the error you were getting was serious.
The problem was on my end (In my code, I intercepted orientations as a 
named argument but assumed it being passed through **kwargs). I 
reverted to the original. Thanks for your patience. I'm sorry.
> 2) Your changes appear to be, mainly, cosmetic. This is good but may
> cause issues with some of the PEP8 pull requests we have been getting.
> Have you rebased to make sure these changes are incorporated?
I rebased off master after pulling from origin. That's correct, right?
> 3) Inline with my PEP8 remark in 2) above. You have some lines (maybe
> only one or two) that look longer than 79 characters.
I re-wrapped everything to 79 characters.
> Other than that, I think you should turn this into a pull request so
> you can get more feedback on an interactive level.
>
> Best,
> Damon
>

There seems to be an issue with how arguments are parsed when it comes
to determining the color of a line. Generally, it seems that 'c'
takes precedence over 'color'. However, this precedence seems to
change with the number of passed kwargs.
-------------
import matplotlib.pyplot as plt
import numpy as np
# 'c' seems to have precedence over 'color'
plt.plot(np.arange(10)-2, c='b', color='r') # line is blue
plt.plot(np.arange(10)-1, color='r', c='b') # line is blue
# But...
x = {'c': 'b',
 'color': 'r',
 'label': 'blah',
 'linestyle': '-',
 'linewidth': 3,
 'marker': None}
# Some strange parsing error
plt.plot(np.arange(10)+1, **x) # line is red
del x['marker'] # delete any key but 'c' or 'color'
plt.plot(np.arange(10)+2, **x) # line is blue
x['zorder'] = 3 # add back any key
plt.plot(np.arange(10)+3, **x) # line is red
plt.show()

On Tue, Oct 16, 2012 at 2:55 PM, Kevin Davies <kda...@gm...> wrote:
> Hello,
>
> I made a few minor changes to the Sankey class. They are listed at:
> https://github.com/kdavies4/matplotlib/compare/master...sankey5
>
> Please review this and let me know if I can submit a pull request.
>
> Thanks.
>
> Kevin
Thanks for taking the time to fix up a part of the codebase!
If you make a pull request out of your code, we'll be able to leave
inline comments on your patches. Nonetheless, I have some feedback for
you after a (very) quick glance:
1) I don't think 'orientations' is a python keyword. What is the error
you were getting? In any case, changing it breaks backwards
compatibility so I'd be an advocate of keeping 'orientations'. Unless,
of course, the error you were getting was serious.
2) Your changes appear to be, mainly, cosmetic. This is good but may
cause issues with some of the PEP8 pull requests we have been getting.
Have you rebased to make sure these changes are incorporated?
3) Inline with my PEP8 remark in 2) above. You have some lines (maybe
only one or two) that look longer than 79 characters.
Other than that, I think you should turn this into a pull request so
you can get more feedback on an interactive level.
Best,
Damon
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

<html>
 <head>
 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 </head>
 <body bgcolor="#FFFFFF" text="#000000">
 <meta http-equiv="content-type" content="text/html;
 charset=ISO-8859-1">
 Hello,<br>
 <br>
 I made a few minor changes to the Sankey class.&nbsp; They are listed at:<br>
 <a
 href="https://github.com/kdavies4/matplotlib/compare/master...sankey5">https://github.com/kdavies4/matplotlib/compare/master...sankey5</a><br>
 <br>
 Please review this and let me know if I can submit a pull request.<br>
 <br>
 Thanks.<br>
 <br>
 Kevin
 </body>
</html>

> In the meantime, PEP8 PRs can be completed on master, after which feature
enhancements can proceed on master.
I think it would be helpful to hold fire on the PEP8 changes until we have
our rc3 and have merged it back onto master for (hopefully) the last time.
That way, we wont have to deal with the conflicts that are inevitable when
merging v1.2.x back to master.
> Any merge conflicts with the PEP8 work will be noted by git and we can
address them as they come.
That is another approach which will work, assuming the master is fairly
up-to-date with v1.2.x now.
> Any strong objections to this?
Nope. Sounds like a good plan.
> In short, provided we can agree a future matplotlib version schedule, I
agree with Eric.
Mike, Ben, Eric & others, there is a new thread relating to scheduling of
releases, it is my opinion that it would be really beneficial to have a
planned release date for v1.3 (and maybe even v1.4/v2.0) that we all agree
on.
Phil
On 15 October 2012 17:59, Michael Droettboom <md...@st...> wrote:
> On 10/15/2012 12:52 PM, Eric Firing wrote:
> > On 2012年10月15日 5:50 AM, Michael Droettboom wrote:
> >> Sorry to be jumping in on this late -- I didn't have a chance to catch
> >> up with this over the weekend.
> >>
> >> I think I generally side with Eric here -- the rc candidate cycle is
> >> intended to be quite conservative. Nelle's pull requests are very
> >> welcome improvements, but they are also quite large and I am concerned
> >> about breakage slipping through the cracks. To the extent that Nelle is
> >> finding undefined variable bugs etc. with her tool, I think we should
> >> probably try and fix those -- I know we've been doing that already and
> >> that's great.
> >>
> >> I think we should take the 1.2.x milestone off of all of the PEP8
> >> changes and keep all of them on master going forward. Yes, the merging
> >> may be difficult while we are still in maintaining 1.2.x, but I think
> >> that's trivial compared to all of the additional testing and push back
> >> of the 1.2.0 release that this is currently causing.
> >>
> >> As for backing out things that were already cherry-picked -- that's a
> >> tough call. I don't want to exacerbate the situation by causing further
> >> risk. Maybe we just back out everything since the rc2?
> > It looks like that would itself cause a huge amount of additional churn,
> > and more risk than leaving things as they are. At this point I suggest
> > leaving everything in that is presently in, try to get in the last few
> > bug fixes and tweaks, tag an rc3, and then target a release date,
> > somewhere in in the 2-4 weeks hence range. In the meantime, PEP8 PRs
> > can be completed on master, after which feature enhancements can proceed
> > on master.
>
> Yeah -- having just looked back at all of the cherry-picks at issue,
> that's where I've come down as well. Let's leave them in, but not put
> any further PEP8-only fixes on 1.2.x. I'll remove the 1.2.x issue
> labels on the few PRs in progress.
>
> I also think it's not the end of the world if additional feature
> enhancements go on in master in the meantime. Any merge conflicts with
> the PEP8 work will be noted by git and we can address them as they come.
>
> Any strong objections to this?
>
> Mike
>
> >
> > Eric
> >
> >> Mike
> >>
> >> On 10/15/2012 12:10 AM, Eric Firing wrote:
> >>> On 2012年10月14日 12:44 PM, Damon McDougall wrote:
> >>>> On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing <ef...@ha...>
> wrote:
> >>>>> All,
> >>>>>
> >>>>> I think we are in a messy situation, and we need to reach some
> agreement
> >>>>> as to how to proceed. This has been discussed a bit in this thread:
> >>>>>
> >>>>>
> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
> >>>>>
> >>>>> The name of that thread did not reflect the importance of the
> discussion
> >>>>> it prompted, hence the present message.
> >>>>>
> >>>>> To summarize my view:
> >>>>>
> >>>>> 1) We have a flood of PEP8 PRs based on master, many of which have
> been
> >>>>> merged, some by myself--so I have no objection to this aspect of the
> >>>>> situation, though I would have preferred a slower pace, a garden hose
> >>>>> rather than a fire hose. I am happy to see continued merging of
> these
> >>>>> PRs into master.
> >>>>>
> >>>>> 2) We are also trying to stabilize v1.2.x, getting in the last few
> bug
> >>>>> fixes and doc updates, so we can get a release out, with a high
> >>>>> probability that it will be solid.
> >>>>>
> >>>>> 3) The potential disagreement is over whether the PEP8 changes
> should be
> >>>>> cherry-picked into v1.2.x, or simply left in master. I favor the
> latter
> >>>>> course. First, because massive code churn shortly before a release
> >>>>> seems unwise. Second, because I think we should stick to the
> strategy
> >>>>> we started with, in which an effort is made to choose the most
> >>>>> appropriate target for each PR, frequently merge the maintenance
> branch
> >>>>> into master, and reserve cherry-picking for occasional corrections.
> >>>>>
> >>>>> 4) The PEP8 changes will cause some merge problems no matter what we
> do;
> >>>>> but I think that they can be minimal and manageable if we leave PEP8
> out
> >>>>> of v1.2.x, and decide that once it is released, v1.2.x will be
> changed
> >>>>> only if critical bugs are found, requiring a v1.2.1 release. This
> also
> >>>>> assumes that we have only a few changes left to be made in v1.2.x
> before
> >>>>> a final rc and a release.
> >>>>>
> >>>>> Therefore I recommend that the PEP8 changes that have already been
> >>>>> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x
> >>>>> milestone be removed from all PEP8 changes.
> >>>>>
> >>>>> If some of the PEP8 commits include genuine bug-fixes that need to
> be in
> >>>>> v1.2.x, then these fixes should be made via PRs directly against
> v1.2.x.
> >>>>>
> >>>>> Agreement? Disagreement? Discussion? Related aspects of strategy?
> >>>>>
> >>>>> Eric
> >>>> I'm happy with whatever is decided. I'd rather not have merge
> >>>> conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to
> >>>> not cherry-pick them into 1.2.x.
> >>>>
> >>>> If it is decided that we are to revert all the PEP8 changes in 1.2.x,
> >>>> what should be done about PEP8 changes that were merged into master
> >>>> before the v1.2.x branch was created?
> >>>>
> >>> Damon,
> >>>
> >>> As I said, I would not advocate trying to back out everything, and
> maybe
> >>> not any of what is already in 1.2.x, or maybe just the most recent
> >>> bunch. Anticipating that Mike D. might want to make a decision
> tomorrow
> >>> (or today from your timezone), perhaps it would be helpful if you could
> >>> make an approximate map of which PEP8 commits were cherry-picked to
> >>> 1.2.x, and how recently? I have been trying to figure this out with
> >>> qgit and git log with various options, but it makes my head spin.
> >>>
> >>> Thanks.
> >>>
> >>> Eric
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Don't let slow site performance ruin your business. Deploy New Relic
> APM
> >>> Deploy New Relic app performance management and know exactly
> >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >>> http://p.sf.net/sfu/newrelic-dev2dev
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> ------------------------------------------------------------------------------
> >> Don't let slow site performance ruin your business. Deploy New Relic APM
> >> Deploy New Relic app performance management and know exactly
> >> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >> http://p.sf.net/sfu/newrelic-dev2dev
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>