_PyErr_Display should be available in the CPython-specific API

[5eb571bb-289a-4a8a-a14b-ecb8839d7e2a]

BPO	43377
Nosy	@encukou, @maxbelanger, @pablogsal
PRs	python/cpython#24719

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['expert-C-API', 'type-feature', '3.10'] title = '_PyErr_Display should be available in the CPython-specific API' updated_at = user = 'https://bugs.python.org/MaximeBelanger' ``` bugs.python.org fields: ```python activity = actor = 'pablogsal' assignee = 'none' closed = False closed_date = None closer = None components = ['C API'] creation = creator = 'Maxime Belanger' dependencies = [] files = [] hgrepos = [] issue_num = 43377 keywords = ['patch'] message_count = 5.0 messages = ['387965', '398304', '398320', '398355', '398356'] nosy_count = 4.0 nosy_names = ['petr.viktorin', 'Maxime Belanger', 'maxbelanger', 'pablogsal'] pr_nums = ['24719'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue43377' versions = ['Python 3.10'] ```

[5eb571bb-289a-4a8a-a14b-ecb8839d7e2a]

We have found _PyErr_Display to be quite helpful in embedding situations, in particular as a way to capture errors to a custom buffer rather than to stderr. Otherwise, embedders often have to replicate logic in PyErr_Print, etc.

Since the header restructuring in Python 3.8+, that function is a bit harder to call. It's exported, but is considered "internal" and thus requires defining Py_BUILD_CORE.

I was wondering: why not expose it under "Include/cpython"? It seems like a generic-enough helper, similar to _PyErr_WriteUnraisableMsg.

[encukou]

If it should be exposed, it should be renamed to a public (non-underscored) name, like PyErr_DisplayToFile. It should also ideally get documentation and tests (along with PyErr_Display, which is sadly missing those as well).

(Also, note that there are no no API/ABI compatibility guarantees if you use private API or define Py_BUILD_CORE. Functions like _PyErr_Display could change/disappear in a patch version of CPython.)

[pablogsal]

PyErr_Display is not exposed partially because is full of small details of the interpreter and we change it constantly without regard for backwards compatibility on purpose. Exposing it will restrict us a lot on how we display error messages or the arguments it may take, so I woulf prefer to not expose it.

[encukou]

PyErr_Display (without underscore) is already exposed. This issue is about adding a variant with an additional output file argument.

The function formats an exception "just as Python would". The exact output will naturally be different between versions, but the function is still useful.

I'm also not sold on the "the arguments it may take" restriction:

• exceptions generally carry all of their context around
• even if they don't in the future, we'll always need a function that takes "just" an exception, for cases where some additional context isn't available

[pablogsal]

PErr_Display (without underscore) is already exposed. This issue is about adding a variant with an additional output file argument.

Oh, I was not aware of that :( Apologies for the confusion!

[serhiy-storchaka]

I concur with @encukou. If you want to add a new public C API, it should be proposed to the C API Workgroup (https://github.com/capi-workgroup).