On 08/13/2010 10:35 AM, Benjamin Root wrote:
On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <efiring@…229… > > mailto:efiring@...229...> wrote:
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.
> tracking down actual source of the problem. Fixing it there
> right thing to do.
> I am assuming that we would like this patched in the maintenance
> too, right? Also, because the doc and the output of the
> .to_rgba_array() function is changing, should it be noted in the
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
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...)
I have dug further about this. I have found that the hist() function,
as well as the bar family of functions are impacted by this issue.
However, for hist(), if you try passing in ‘none’ for color in the old
version, it errors out saying that it needs some color info. With this
corrected version, it doesn’t error, but there are no lines drawn as
well (I have to see if that is another bug).
The other place where I can see how this fix might cause issues is with
regards to Collections and the classes that derive from that.
While I certainly think that the current behavior of to_rgba_array() is
wrong, I am starting to get hesitant about changing this because there
might be some sort of fundamental difference between how the backends
are treating “array(, shape=(0, 4), dtype=float64)” and "array([0.,
0., 0., 0.])". The first is really easy to use as a "don’t draw
anything" whereas the latter isn’t that obvious to the backends.
A particular case where this might cause trouble is for graphics formats
that do not support transparencies. Because “array([0., 0., 0., 0.])”
is fully transparent black, in formats like eps with a non-black
background, the objects with this color will appear – although, it is
already possible to do that with bar(…, color=[‘none’]).