gh-125593: Use colors to highlight error locations in tracebacks from exception group

[wrongnull]

• Issue: colors are missing on (Base)ExceptionGroup tracebacks in the pyrepl #125593

[Eclips4]

We also need to test for the presence of the magenta color, and, more importantly, we need to ensure that the exception group has been colored and that their sub-exception have also been colored.

[Eclips4]

@pablogsal @Yhg1s I think this is on the boundary between a bug fix and a feature, so I wanted to ask for your opinion on backporting it to the 3.13 branch. This pull request is pretty trivial, so I would like to consider it a bug fix.

[pablogsal]

It's 100% bug, colors should apply to all exceptions, not just normal ones (as it's documented).

[Yhg1s]

Yes, treating this as a bug seems correct, given that the traceback is now partially colourised.

[wrongnull]

I'm converting it to a draft while I struggle with test debugging.

[wrongnull]

I definitely underestimated myself

[wrongnull]

We can't just construct a expected string and compare it's to the actual message from traceback due to that fact that on Windows x86 <object at 0x...> can't be constructed using the f"<object at {hex(id(obj))}>" because it has different formatting for pointers...:

First differing element 5:
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x06176570>'
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x6176570>'

@pablogsal What do you think? Is the current approach looks good to you or it need to be more generic?

[pablogsal]

We can't just construct a expected string and compare it's to the actual message from traceback due to that fact that on Windows x86 <object at 0x...> can't be constructed using the f"<object at {hex(id(obj))}>" because it has different formatting for pointers...:

First differing element 5:
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x06176570>'
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x6176570>'

@pablogsal What do you think? Is the current approach looks good to you or it need to be more generic?

You could use the real foo object in the f-string so it's formatted directly in the expectation no? That will respect whatever custom formatting is done per platform

[wrongnull]

You could use the real foo object in the f-string so it's formatted directly in the expectation no? That will respect whatever custom formatting is done per platform

I can't. Since pointer formatting is implementation-defined behavior, 32-bit MSVC omits leading zero in formatted string

[wrongnull]

We can't just construct a expected string and compare it's to the actual message from traceback due to that fact that on Windows x86 <object at 0x...> can't be constructed using the f"<object at {hex(id(obj))}>" because it has different formatting for pointers...:

First differing element 5:
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x06176570>'
'  | [54 chars]zed_traceback_from_exception_group.<locals>.foo at 0x6176570>'

@pablogsal What do you think? Is the current approach looks good to you or it need to be more generic?

You could use the real foo object in the f-string so it's formatted directly in the expectation no? That will respect whatever custom formatting is done per platform

I apologize for the misunderstanding. Appropriate changes have been made.