cuvner is incompatible with ansicolors 1.1.6 about cuvner HOT 9 OPEN

Merely changing that string to a unicode literal will break usage like color(encoded_utf8_bytes) though. Really, "bytes or unicode" is not a happy type to have to work with.

from cuvner.

Hmm, looks like https://github.com/jonathaneunice/colors/blob/master/colors/colors.py#L109 should be a unicode literal to work properly on Python2?

from cuvner.

Seems plausible - but the docstring for color makes it unclear whether the function is meant to operate on bytes or unicode.

from cuvner.

otoh, reading the return docs suggests yes it should work on unicode.

from cuvner.

Looks to me like this was unintended fallout from this commit: jonathaneunice/colors@67dd97f#diff-3358adf77afc6138373d66e0d18cd3b6L101

...because: str + unicode + str will be a unicode, but str.format(unicode) will not be...

from cuvner.

"Yes" to your last comment. Hmm... I'll file an issue on colors and see what we come up with? But this will just not work, ever: "something {}".format(u"\u258f") and yeah the docstring says I should be able to give it a unicode string and get a unicode back...

from cuvner.

Hmm, maybe @jonathaneunice can comment here? It seems colors isn't using the github bugtracker (and I don't see any other thing being used).

from cuvner.

I guess for now I can pin cuvner to 1.0.2

from cuvner.

Okay, I did that and released 17.3.0

from cuvner.