Normalized Hex

[samgoodrich1]

I just wanted to say thank you for working on things like this. Your color range list function was a lifesaver for me. I did have a problem once in a while with matplotlib where it wouldn't recognize a non-normalized web hex format. For example, a value in the middle of a range landed on #393. Matplotlib wouldn't take this value as it apparently needed the normalized #339933. I used the webcolors package to normalize the output of my color range lists from colour to avoid the random problem of landing on a color value that didn't need all 6 digits to represent it. Before webcolors I tried formatting the color value using "%s"% and .hex but it remained a 3 digit color value that matplotlib wouldn't take. The piece of code they use to normalize is this: if len(hex_digits) == 3: hex_digits = u''.join(2 * s for s in hex_digits)

If I'm going about this reporting wrong maybe you can let me know what I should be doing differently. I'm new to open source projects like this. Thanks.

Sam

[katzenbaer]

👍 I would also appreciate a native way to consistently get the 6-hex representation.

EDIT: Until native support, @samgoodrich1's workaround is basically this:

import webcolors
normalized_color = webcolors.normalize_hex('#393')  # will return u'#339933'

[vaab]

I'm not sure I understand your request::

import colour
colour.Color("#393").hex_l

Did you know about hex_l ? This is around since June 2012. Maybe this is not advertised I'll fix this in README.rst.

Thank you for your reports !

[samgoodrich1]

I was not aware of hex_l. That is good to know. Is there a reason why hex is not normalized to 6 digits? The two lines of code from webcolors as seen in my original post would seem to work to fix hex. Thanks for the reply.

[katzenbaer]

@vaab Thanks for pointing that out, I wasn't aware of its existence either. Worth mentioning to anyone reading this in the future, the attribute name is 'HEX_L'.lower() # hex_l not 'HEX_1'.lower() # hex_1 (I'm guessing it stands for Hex Long?)

[vaab]

@samgoodrich1 hum, that's a good question. Do we want hex string representation to be long by default ? I'm inclined to think you might be right and that it should have been long. But for backwards-compatibility's sake, I guess that we should continue with the historical version as long as the hex_l is clearly mentioned in the docs. Sorry for having missed your post and took so long to give you this answer.

@katzenbaer yes hex_l, the L letter stands for "long".

[vaab]

version 1.3 is released with the mention in the doc.