You can choose a color that includes alpha, i.e. #ffffff88.

Thanks, I also see this is a duplicate of issue #5132.

@mdboom, the hex colorspec does not support the optional alpha channel. It
is an open feature request to add such support. If the support is there
deep in the colors.py code and I did not see it, then the validator needs
to be updated.

On Wed, Nov 11, 2015 at 8:57 AM, evandhall notifications@github.com wrote:

Thanks, I also see this is a duplicate of issue #5132
#5132.

—
Reply to this email directly or view it on GitHub
#5461 (comment)
.

Ok -- sorry for creating confusion. If it isn't supported, I think it should be. I think separating color from alpha has been a long term mistake. To the extent that we're cleaning up color usage and specification, I think we should encourage more use of RGBA.

This issue also makes #6196 (Qt editor drops alpha) difficult to solve. I am willing to tackle this but would also like to take advantage of this to deprecate some old stuff (because there's going to be some API breakage anyways).

I think the public color conversion API should be something like:

• is_color_like (any -> bool),
• to_hex (3-tuple -> #rrggbb, 4-tuple or other color-like -> #rrggbbaa),
• to_rgba (any -> 4-tuple),
• to_rgba_array
  (module-level functions)

and drop out rgb2hex, hex2color (both are confusing in the presence of alpha) and the whole colorConverter class (by the way I haven't managed to make the "Cn" syntax work but it looks like caching on that class would lead to issues if someone changes the rcParams in between?).

It is not obvious to me that this requires breaking any API or removing any functionality.

We need to keep the rgb only version around because some backends (ps) do not support alpha.

I think this and #5132 should be closed by #6382.

closed via #6382