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
------------------------------------------------------------------------------
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
