On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <efir...@hawaii.edu> 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. 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
>
>
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']).
What I think we have here is a need for a consistent way to indicate "I am
never to be drawn" that fits in with the current paradigm of the rgba
arrays. Maybe nan in the alpha channel?
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
