WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Conversation

@keturn
Copy link
Contributor

@keturn keturn commented Jan 5, 2020

Here are a few test cases demonstrating failures when colorful makes ColorfulStrings out of non-string objects.

s.red(1) + s.red(2) case is particularly fun for generating quirky results that sneak by without raising exceptions.

keturn added 2 commits January 5, 2020 14:20
It's sneaky because it gives different results when under NO_COLORS and
slips through without raising exceptions.
@keturn
Copy link
Contributor Author

keturn commented Jan 5, 2020

Not sure how you'd like to handle this.

The thing that seems most obvious to me is for ColorfulStyle.evaluate to str() everything that comes in, so that ColorfulString.orig_string is always a string.

Strictly speaking, that won't be 100% backwards compatible, because you'll be executing the input's __str__ earlier than you would have, and things like ColorfulString.__format__ will no longer call the original object's __format__.

but since style_string freezes its input as a string at that time anyway, it's probably the only thing that makes sense, to do them both at the same time.

@keturn
Copy link
Contributor Author

keturn commented Jan 5, 2020

And while I'm looking at ColorfulString, I notice __len__ uses orig_string but __iter__ uses styled_string.

Is that intentional? Should __iter__ at least switch on colormode == NO_COLORS?

@fliiiix
Copy link
Collaborator

fliiiix commented Sep 24, 2025

are you still interested in this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants