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.

[Eclips4]

LGTM.
@pablogsal what do you think about the current approach to testing it?

[pablogsal]

LGTM

[miss-islington-app]

Thanks @wrongnull for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[pablogsal]

Thanks a lot for the fix @wrongnull and thanks for the review @Eclips4 !

[bedevere-app]

GH-126021 is a backport of this pull request to the 3.13 branch.