matplotlib-devel Mailing List for matplotlib

On 08/12/2010 10:40 AM, Benjamin Root wrote:
[...]
> >
> > >>> mcolor.colorConvertor.to_rgba_array('none')
> > array([], shape=(0, 4), dtype=float64)
> >
> > >>> mcolor.colorConvertor.to_rgba_array(['none'])
> > array([[ 0., 0., 0., 0.]])
> >
> > >>> mcolor.colorConvertor.to_rgba_array('r')
> > array([[ 1., 0., 0., 1.]])
> >
> > Should this be regarded as a bug?
>
> Yes, 'none' should be handled uniformly by that method. Thanks for
> tracking down actual source of the problem. Fixing it there is the
> right thing to do.
>
> Eric
>
>
> I am assuming that we would like this patched in the maintenance branch,
> too, right? Also, because the doc and the output of the
> .to_rgba_array() function is changing, should it be noted in the changelog?
Yes, bugs should be squashed first in the maintenance branch, and 
svnmerge should be used to propagate the change to the trunk. If 
to_rgba_array is not treating "none" and ["none"] the same way, that is 
a bug.
But... now I'm looking at the to_rgba_array method, and wondering why it 
is specifying that special case handling of "none". The present code 
implementing that special case is mine, but I suspect I was just 
maintaining legacy behavior, as Darren had added this special case 
explicitly to the docstring long before my code change.
So it is looking more complicated than I thought. I suppose the course 
of action most consistent with the idea of a maintenance branch and a 
trunk would be to put the change in the trunk, since it is changing the 
documented behavior of a key method. Then the choices for the 
maintenance branch would be to work around the behavior, as in Ben 
North's patch, or to do nothing. If you work around it, I think it will 
require special attention to keep svnmerge from erroneously adding the 
workaround to the trunk the next time svnmerge is run. So, if you 
choose to do that at all, I would suggest waiting until you are sure how 
to handle that svnmerge aspect; maybe it is documented.
Also, with the change to to_rgba_array in the trunk, you will need to do 
some exploration to figure out whether any other code will need to be 
changed to take advantage of it, or to allow for it. (I may have had a 
reason for maintaining the bizarre legacy behavior the last time I 
changed the code in that method...)
Eric
>
> Ben Root

On 08/12/2010 09:56 AM, Benjamin Root wrote:
> Btw, the current set of tests has a failure for testing pcolormesh.
> Wasn't there a change fairly recently to fix a problem with pcolormesh,
> so that the test image should now be updated?
Mike did update the images a couple weeks ago, and when I run the tests, 
I don't get that failure. Is it possible that you have not done a clean 
rebuild and install since Mike's changes?
Eric
>
> Ben Root

On Thu, Aug 12, 2010 at 12:37 PM, Eric Firing <ef...@ha...> wrote:
> On 08/12/2010 06:09 AM, Benjamin Root wrote:
> > On Thu, Aug 12, 2010 at 10:13 AM, Ben North <be...@re...
> > <mailto:be...@re...>> wrote:
> >
> > Ben Root:
> > >Ben North:
> > >> Same kind of thing with
> > >> the kwarg 'color' instead of 'edgecolor', which is also fixed in
> my
> > >> second recent email.
> > >
> > > Looking through the code for bar(), I see the same thing occurs
> > for the
> > > 'color' keyword argument. So I guess we should fix that as well.
> >
> > Yes, the second of the emails I sent (pasted below) fixes the
> behaviour
> > for 'edgecolor' and 'color'. Thanks for committing this.
> >
> > Ben.
> >
> >
> ------------------------------------------------------------------------
> >
> >
> > Date: 9 August 2010 09:42
> > Subject: Handle 'none' as color and edgecolor for bar()
> >
> > Hi,
> >
> > Update to my recent email: perhaps it would make sense to handle the
> > 'color' argument in the same way, allowing hollow bars. Combined
> patch
> > below.
> >
> > Ben.
> >
> >
> >
> > --- ORIG-axes.py 2010年07月06日 15:43:35.000000000 +0100
> > +++ NEW-axes.py 2010年08月09日 09:39:44.000256000 +0100
> > @@ -4575,15 +4575,17 @@
> > if len(linewidth) < nbars:
> > linewidth *= nbars
> >
> > - if color is None:
> > - color = [None] * nbars
> > + if (color is None
> > + or (is_string_like(color) and color.lower() == 'none')):
> > + color = [color] * nbars
> > else:
> > color = list(mcolors.colorConverter.to_rgba_array(color))
> > if len(color) < nbars:
> > color *= nbars
> >
> > - if edgecolor is None:
> > - edgecolor = [None] * nbars
> > + if (edgecolor is None
> > + or (is_string_like(edgecolor) and edgecolor.lower() ==
> > 'none')):
> > + edgecolor = [edgecolor] * nbars
> > else:
> > edgecolor =
> > list(mcolors.colorConverter.to_rgba_array(edgecolor))
> > if len(edgecolor) < nbars:
> >
> >
> >
> > I did a little more checking to see if this was needed elsewhere and I
> > think this is the wrong patch to apply. It appears that
> > colorConverter.to_rgba_array() might not be correctly handling the case
> > of 'none'. If one passes in a list of colors with some of them being
> > 'none', everything works nicely. However, if one passes in just 'none',
> > then it returns an empty array. Note that passing in ['none'] to
> > .to_rgba_array() produces a length 1 array.
> >
> > >>> mcolor.colorConvertor.to_rgba_array('none')
> > array([], shape=(0, 4), dtype=float64)
> >
> > >>> mcolor.colorConvertor.to_rgba_array(['none'])
> > array([[ 0., 0., 0., 0.]])
> >
> > >>> mcolor.colorConvertor.to_rgba_array('r')
> > array([[ 1., 0., 0., 1.]])
> >
> > Should this be regarded as a bug?
>
> Yes, 'none' should be handled uniformly by that method. Thanks for
> tracking down actual source of the problem. Fixing it there is the
> right thing to do.
>
> Eric
>
>
I am assuming that we would like this patched in the maintenance branch,
too, right? Also, because the doc and the output of the .to_rgba_array()
function is changing, should it be noted in the changelog?
Ben Root

On Thu, Aug 12, 2010 at 2:39 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Aug 12, 2010 at 2:34 PM, Benjamin Root <ben...@ou...> wrote:
> > I am currently working to patch something in colors.py and I am coming
> > across a lot of older style code and code that duplicates functionality
> that
> > can be found in cbook.py (particularly the type-checking functions). Is
> > there a standing rule that code that we come across should get updated or
> > adapted to use the functions in cbook.py?
> >
> > Or is it the other way around and that we should be avoiding cbook.py?
>
> You should be using as much centralized functionality (eg cbook) as
> possible and clean-ups are welcome. Just make sure if you remove a
> func that may be outward facing (eg a duplicate function from
> colors.py) that you deprecate it with a warning and note it in the
> log, and that the regression tests are passing.
>
> Thanks for the efforts!
> JDH
>
Ok, good to know.
Btw, the current set of tests has a failure for testing pcolormesh. Wasn't
there a change fairly recently to fix a problem with pcolormesh, so that the
test image should now be updated?
Ben Root

On Thu, Aug 12, 2010 at 2:34 PM, Benjamin Root <ben...@ou...> wrote:
> I am currently working to patch something in colors.py and I am coming
> across a lot of older style code and code that duplicates functionality that
> can be found in cbook.py (particularly the type-checking functions). Is
> there a standing rule that code that we come across should get updated or
> adapted to use the functions in cbook.py?
>
> Or is it the other way around and that we should be avoiding cbook.py?
You should be using as much centralized functionality (eg cbook) as
possible and clean-ups are welcome. Just make sure if you remove a
func that may be outward facing (eg a duplicate function from
colors.py) that you deprecate it with a warning and note it in the
log, and that the regression tests are passing.
Thanks for the efforts!
JDH

I am currently working to patch something in colors.py and I am coming
across a lot of older style code and code that duplicates functionality that
can be found in cbook.py (particularly the type-checking functions). Is
there a standing rule that code that we come across should get updated or
adapted to use the functions in cbook.py?
Or is it the other way around and that we should be avoiding cbook.py?
Thanks,
Ben Root

On 08/12/2010 06:09 AM, Benjamin Root wrote:
> On Thu, Aug 12, 2010 at 10:13 AM, Ben North <be...@re...
> <mailto:be...@re...>> wrote:
>
> Ben Root:
> >Ben North:
> >> Same kind of thing with
> >> the kwarg 'color' instead of 'edgecolor', which is also fixed in my
> >> second recent email.
> >
> > Looking through the code for bar(), I see the same thing occurs
> for the
> > 'color' keyword argument. So I guess we should fix that as well.
>
> Yes, the second of the emails I sent (pasted below) fixes the behaviour
> for 'edgecolor' and 'color'. Thanks for committing this.
>
> Ben.
>
> ------------------------------------------------------------------------
>
>
> Date: 9 August 2010 09:42
> Subject: Handle 'none' as color and edgecolor for bar()
>
> Hi,
>
> Update to my recent email: perhaps it would make sense to handle the
> 'color' argument in the same way, allowing hollow bars. Combined patch
> below.
>
> Ben.
>
>
>
> --- ORIG-axes.py 2010年07月06日 15:43:35.000000000 +0100
> +++ NEW-axes.py 2010年08月09日 09:39:44.000256000 +0100
> @@ -4575,15 +4575,17 @@
> if len(linewidth) < nbars:
> linewidth *= nbars
>
> - if color is None:
> - color = [None] * nbars
> + if (color is None
> + or (is_string_like(color) and color.lower() == 'none')):
> + color = [color] * nbars
> else:
> color = list(mcolors.colorConverter.to_rgba_array(color))
> if len(color) < nbars:
> color *= nbars
>
> - if edgecolor is None:
> - edgecolor = [None] * nbars
> + if (edgecolor is None
> + or (is_string_like(edgecolor) and edgecolor.lower() ==
> 'none')):
> + edgecolor = [edgecolor] * nbars
> else:
> edgecolor =
> list(mcolors.colorConverter.to_rgba_array(edgecolor))
> if len(edgecolor) < nbars:
>
>
>
> I did a little more checking to see if this was needed elsewhere and I
> think this is the wrong patch to apply. It appears that
> colorConverter.to_rgba_array() might not be correctly handling the case
> of 'none'. If one passes in a list of colors with some of them being
> 'none', everything works nicely. However, if one passes in just 'none',
> then it returns an empty array. Note that passing in ['none'] to
> .to_rgba_array() produces a length 1 array.
>
> >>> mcolor.colorConvertor.to_rgba_array('none')
> array([], shape=(0, 4), dtype=float64)
>
> >>> mcolor.colorConvertor.to_rgba_array(['none'])
> array([[ 0., 0., 0., 0.]])
>
> >>> mcolor.colorConvertor.to_rgba_array('r')
> array([[ 1., 0., 0., 1.]])
>
> Should this be regarded as a bug?
Yes, 'none' should be handled uniformly by that method. Thanks for 
tracking down actual source of the problem. Fixing it there is the 
right thing to do.
Eric
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, Aug 12, 2010 at 10:13 AM, Ben North <be...@re...> wrote:
> Ben Root:
> >Ben North:
> >> Same kind of thing with
> >> the kwarg 'color' instead of 'edgecolor', which is also fixed in my
> >> second recent email.
> >
> > Looking through the code for bar(), I see the same thing occurs for the
> > 'color' keyword argument. So I guess we should fix that as well.
>
> Yes, the second of the emails I sent (pasted below) fixes the behaviour
> for 'edgecolor' and 'color'. Thanks for committing this.
>
> Ben.
>
> ------------------------------------------------------------------------
>
>
> Date: 9 August 2010 09:42
> Subject: Handle 'none' as color and edgecolor for bar()
>
> Hi,
>
> Update to my recent email: perhaps it would make sense to handle the
> 'color' argument in the same way, allowing hollow bars. Combined patch
> below.
>
> Ben.
>
>
>
> --- ORIG-axes.py 2010年07月06日 15:43:35.000000000 +0100
> +++ NEW-axes.py 2010年08月09日 09:39:44.000256000 +0100
> @@ -4575,15 +4575,17 @@
> if len(linewidth) < nbars:
> linewidth *= nbars
>
> - if color is None:
> - color = [None] * nbars
> + if (color is None
> + or (is_string_like(color) and color.lower() == 'none')):
> + color = [color] * nbars
> else:
> color = list(mcolors.colorConverter.to_rgba_array(color))
> if len(color) < nbars:
> color *= nbars
>
> - if edgecolor is None:
> - edgecolor = [None] * nbars
> + if (edgecolor is None
> + or (is_string_like(edgecolor) and edgecolor.lower() ==
> 'none')):
> + edgecolor = [edgecolor] * nbars
> else:
> edgecolor =
> list(mcolors.colorConverter.to_rgba_array(edgecolor))
> if len(edgecolor) < nbars:
>
I did a little more checking to see if this was needed elsewhere and I think
this is the wrong patch to apply. It appears that
colorConverter.to_rgba_array() might not be correctly handling the case of
'none'. If one passes in a list of colors with some of them being 'none',
everything works nicely. However, if one passes in just 'none', then it
returns an empty array. Note that passing in ['none'] to .to_rgba_array()
produces a length 1 array.
>>> mcolor.colorConvertor.to_rgba_array('none')
array([], shape=(0, 4), dtype=float64)
>>> mcolor.colorConvertor.to_rgba_array(['none'])
array([[ 0., 0., 0., 0.]])
>>> mcolor.colorConvertor.to_rgba_array('r')
array([[ 1., 0., 0., 1.]])
Should this be regarded as a bug?
Ben Root

Ben Root:
>Ben North:
>> Same kind of thing with
>> the kwarg 'color' instead of 'edgecolor', which is also fixed in my
>> second recent email.
>
> Looking through the code for bar(), I see the same thing occurs for the
> 'color' keyword argument. So I guess we should fix that as well.
Yes, the second of the emails I sent (pasted below) fixes the behaviour
for 'edgecolor' and 'color'. Thanks for committing this.
Ben.
------------------------------------------------------------------------
Date: 9 August 2010 09:42
Subject: Handle 'none' as color and edgecolor for bar()
Hi,
Update to my recent email: perhaps it would make sense to handle the
'color' argument in the same way, allowing hollow bars. Combined patch
below.
Ben.
--- ORIG-axes.py 2010年07月06日 15:43:35.000000000 +0100
+++ NEW-axes.py 2010年08月09日 09:39:44.000256000 +0100
@@ -4575,15 +4575,17 @@
 if len(linewidth) < nbars:
 linewidth *= nbars
- if color is None:
- color = [None] * nbars
+ if (color is None
+ or (is_string_like(color) and color.lower() == 'none')):
+ color = [color] * nbars
 else:
 color = list(mcolors.colorConverter.to_rgba_array(color))
 if len(color) < nbars:
 color *= nbars
- if edgecolor is None:
- edgecolor = [None] * nbars
+ if (edgecolor is None
+ or (is_string_like(edgecolor) and edgecolor.lower() == 'none')):
+ edgecolor = [edgecolor] * nbars
 else:
 edgecolor = list(mcolors.colorConverter.to_rgba_array(edgecolor))
 if len(edgecolor) < nbars:

On Mon, Aug 9, 2010 at 10:02 AM, Ben North <be...@re...> wrote:
> >> I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
> >> border to the bars, but instead got no bars at all.
> >
> > Just to note, the documentation does specify a difference between None
> and
> > 'none'. None means to use the rcdefaults and 'none' means no color at
> all.
> > Is bar() just simply not properly handling the 'none' case?
>
> That's right, yes. Currently, bar() does not handle the string 'none'
> properly; it results in an empty graph. E.g.:
>
> bar([1, 2, 3], [12, 13, 14], edgecolor = None)
>
> behaves correctly, giving a bar chart with black-edged blue bars.
>
> bar([1, 2, 3], [12, 13, 14], edgecolor = 'none')
>
> gives no graph at all. After the patch, the second call gives the right
> result, a bar-chart with border-less blue bars. Same kind of thing with
> the kwarg 'color' instead of 'edgecolor', which is also fixed in my
> second recent email.
>
> Hope this clarifies things. Thanks,
>
> Ben.
>
>
Looking through the code for bar(), I see the same thing occurs for the
'color' keyword argument. So I guess we should fix that as well. If no one
has any objections, I can commit this fix.
Ben Root

To avoid having to import MacOS, I've implemented the MacOS.WMAvailable() function in src/_macosx.m. The updated version of backend_macosx.py doesn't import MacOS; see revision 8625 in trunk.
--Michiel.
--- On Tue, 8/10/10, Derek Homeier <de...@as...> wrote:
> From: Derek Homeier <de...@as...>
> Subject: [matplotlib-devel] backend_macosx framework check fails with 64bit Python
> To: mat...@li...
> Date: Tuesday, August 10, 2010, 7:41 AM
> Hi again, cc'ing the matplotlib list
> this time,
> 
> for the latter: when building matplotlib against a
> fink-installed python compiled in 64bit mode
> I found the check for a framework-installed Python (rev
> 8365) fails, and matplotlib fails to load,
> because the MacOS module is not available in 64bit.
> Actually Apple seems to have made it
> still available in their system Python, but it's likely to
> be a general problem on 64bit OS X installations,
> and will be for python3 as well.
> 
> >> 
> >> I believe I have fixed the patch file issue that
> came from an accidental edit of
> >> the patch file (off by 1 space character). 
> For the issues below, can you give
> >> me some examples that show the behavior that is
> broken now, but fixed into your
> >> updated patch? I haven't used matplotlib in
> a long time.
> > 
> > 
> > thanks, the fixed patch in unstable compiles and runs
> now.
> > Sorry for the late reply; I found that the issue that
> my extra patch addressed
> > actually only seems to exist for x86_64 on Snow
> Leopard.
> > It is in fact not directly related to python being
> built as a framework, but the
> > "import MacOS" used to check for the framework version
> fails, since the
> > MacOS module is not available in 64bit. Or so the
> python docs state, but Apple
> > seems to have retrofitted it somehow into their system
> python, so my test for
> > "import MacOS" worked with /usr/bin/python even on
> Snow Leopard.
> > 
> > So the test for MacOS.WMAvailable() that my patch
> removed can obviously stay
> > there for 32bit installations, and it would probably
> be better to just catch the
> > import error on 64bit systems. I'll try to work
> something out along those lines,
> > and probably send it upstream to the matplotlib folks
> as well, since this should
> > be a general problem on 64bit systems; and also the
> MacOS module is going
> > to be removed altogether in python3.x. I'll keep you
> posted.
> > 
> I've put the import inside the check now and have it print
> the warning in both cases
> (assuming Python is not a framework installation if it
> lacks the MacOS module).
> I don't know if there might be an alternative way to check
> for the framework property
> for later, and I just picked an error to raise that seemed
> sensible - feel free to change
> that as necessary.
> 
> Cheers,
>      
>      
>   Derek
> 
> 
> -----Inline Attachment Follows-----
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>