You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to how some runtime environments don't support colors, it may be helpful to programmers that the non-colorized rendering of the ClickException message was available... something I was thinking when encountering and working around #2193.
Color shouldn't matter, nor should creating subclasses be necessary for verifying that the correct user-facing ClickException was raised with a certain message, for example in a test:
"""Tests for ClickException and exception handling."""importclickdeftest_exception_message_no_color():
"""Base Exception message should be plain text."""exception=click.ClickException(click.style('red', fg='red') +' text')
assert'red text'instr(exception) # fails currently
I'd think that __str__, and the possibly the message property too, should be rendered as plain text. I do have a simple StringIO patch that works, as well as just creating a subclass for my code if click is unpatched.
The text was updated successfully, but these errors were encountered:
Similar to how some runtime environments don't support colors, it may be helpful to programmers that the non-colorized rendering of the
ClickException
message was available... something I was thinking when encountering and working around #2193.Color shouldn't matter, nor should creating subclasses be necessary for verifying that the correct user-facing
ClickException
was raised with a certain message, for example in a test:I'd think that
__str__
, and the possibly themessage
property too, should be rendered as plain text. I do have a simpleStringIO
patch that works, as well as just creating a subclass for my code ifclick
is unpatched.The text was updated successfully, but these errors were encountered: