[matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Peter Hansen]

I was just analyzing why 145 colours were listed in 
matplotlib.colors.cnames instead of the 140 that are apparently "HTML 
standard" and, although there's a good reason for that, in the process I 
discovered that an issue reported in 2007 in the mailing list is still 
outstanding in 1.1.0:

http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00669.html

Basically, although there is block of code there to "add british 
equivs", the master list already has the British 'lightgrey' in it, 
instead of 'lightgray'.  For consistency with all the other cases 
('darkgray', 'dimgray', etc) the patch in the message above should be 
applied, with the result that both "lightgray" and "lightgrey" would be 
legal, as all the other types of gray already are.

Is this something I should just ticket, or is a report here sufficient?

Thanks.
-- 
Peter Hansen, P.Eng.
Engenuity Corporation

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Tony Yu]

On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen  wrote:

> I was just analyzing why 145 colours were listed in
> matplotlib.colors.cnames instead of the 140 that are apparently "HTML
> standard" and, although there's a good reason for that, in the process I
> discovered that an issue reported in 2007 in the mailing list is still
> outstanding in 1.1.0:
>
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00669.html
>
> Basically, although there is block of code there to "add british
> equivs", the master list already has the British 'lightgrey' in it,
> instead of 'lightgray'.  For consistency with all the other cases
> ('darkgray', 'dimgray', etc) the patch in the message above should be
> applied, with the result that both "lightgray" and "lightgrey" would be
> legal, as all the other types of gray already are.
>
> Is this something I should just ticket, or is a report here sufficient?
>
> Thanks.
> --
> Peter Hansen, P.Eng.
> Engenuity Corporation


It's a trivial change, but I added a PR to fix
this,
just to make it as easy as possible for the devs.
-Tony
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Eric Firing]

On 03/09/2012 11:42 AM, Tony Yu wrote:
>
>
> On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen  > wrote:
>
> I was just analyzing why 145 colours were listed in
> matplotlib.colors.cnames instead of the 140 that are apparently "HTML
> standard" and, although there's a good reason for that, in the process I
> discovered that an issue reported in 2007 in the mailing list is still
> outstanding in 1.1.0:
>
> 
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00669.html
>
> Basically, although there is block of code there to "add british
> equivs", the master list already has the British 'lightgrey' in it,
> instead of 'lightgray'.  For consistency with all the other cases
> ('darkgray', 'dimgray', etc) the patch in the message above should be
> applied, with the result that both "lightgray" and "lightgrey" would be
> legal, as all the other types of gray already are.
>
> Is this something I should just ticket, or is a report here sufficient?
>
> Thanks.
> --
> Peter Hansen, P.Eng.
> Engenuity Corporation
>
>
> It's a trivial change, but I added a PR to fix this
> , just to make it as
> easy as possible for the devs.

Tony,

Thank you.  If you have time, would you make a new pull request, please, 
against v1.1.x instead of master?  This seems like a bug that might as 
well be fixed before the next maintenance release.  If it goes into 
v1.1.x then it will automatically be included in master as well, as soon 
as someone merges v1.1.x into master.

Eric

> -Tony
>
>
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel