[Feature Request] Visual separation between beartype text and the user input in error messages

Currently beartype does not use symbols etc. to separate the user input from the rest of the error message. When the type violating value is long or its type atypical, it becomes harder for a user to read the error message.

Proposal:

1. Use a symbol to quote the values. The backtick ` symbol can be a good candidate

2. Use colors

3. Do both!

   A more complicated example showing the user input is clearly distinguishable:

   

(1) I am hoping to color the correctly matched type green (*List* index 0 ...). (2) I wasn’t able to find the code that outputs the first line Not <class ...> or ...

Test script

from beartype import beartype

@beartype
def quote_wiggum(lines: list[str] | str) -> None:
    print('“{}”\n\t— Police Chief Wiggum'.format("\n ".join(lines)))
    return lines

def print_exception(func):
    try:
        func()
    except Exception as e:
        print(e)

print_exception(lambda: quote_wiggum(['Hello', 'World']))
print("------")
print_exception(lambda: quote_wiggum([b"Oh, my God! A horrible plane crash!", b"Hey, everybody! Get a load of this flaming wreckage!",]))

yields

@beartyped __main__.quote_wiggum() return `['Hello', 'World']` violates type hint `None`, as list `['Hello', 'World']` not instance of <class "builtins.NoneType">.
------
@beartyped __main__.quote_wiggum() parameter `lines=[b'Oh, my God! A horrible plane crash!', b'Hey, everybody! Get a load of this flaming wrecka...'` violates type hint `list[str] | str`, as list `[b'Oh, my God! A horrible plane crash!', b'Hey, everybody! Get a load of this flaming wrecka...'`:
* Not str.
* List index 0 item bytes `b'Oh, my God! A horrible plane crash!'` not instance of str.

[langfield]

As a mere user, I like this proposal! I have often wondered why colors and quoting were curiously absent from an otherwise extremely feature-complete tool. Although I will admit that the unadorned error messages sort of fit the whole ‘bare-metal’, ‘fast’, ‘lean’ theme of the project. Quoting would be nice though. I’ve gotten used to it, but I definitely remember having a bit of a hard time finding the actual and expected types when I first tried it.

Just my two cents: backticks may present issues for users copying error messages into anything that uses backticks to escape code snippets (e.g. many many things). Git uses plain-old single quotes.

Another question: how do folks feel about error messages that aren’t one, huge, definitely-going-to-be-wrapped line?

[leycec]

Yes to everything above. So much: “Yes!” To answer @langfield’s astute question:

…how do folks feel about error messages that aren’t one, huge, definitely-going-to-be-wrapped line?

Yes to that as well. Insert “Why not both?” meme girl here. Specifically, let’s do it both @justinchuby’s way (because it costs us nothing, aside from admitted backtick issues) and @langfield’s way by additionally emitting a function signature identifying the erroneous parameter or return: e.g.,

BeartypeHintParamViolation: @beartyped __main__.quote_wiggum()
parameter `lines=[b'Oh, my God! A horrible plane crash!', b'Hey,
everybody! Get a load of this flaming wrecka...'` violates type hint
`list[str] | str`, as list `[b'Oh, my God! A horrible plane crash!', b'Hey,
everybody! Get a load of this flaming wrecka...'`:
* Not str.
* List index 0 item bytes `b'Oh, my God! A horrible plane crash!'` not instance of str.

Unbearably Detailed Function Call Diagnosis:
    def quote_wiggum(
        lines: list[str] | str
        ^^^^^^ expected: list[str] | str
        >>>>>> received: bytes b'Hey, everybody! Get a load of this flaming wrecka...'
    ) -> None:

Pretend everything above is ANSII-colourized for glory.