This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: _PyErr_Display should be available in the CPython-specific API
Type: enhancement Stage: patch review
Components: C API Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Maxime Belanger, maxbelanger, pablogsal, petr.viktorin
Priority: normal Keywords: patch

Created on 2021-03-02 20:42 by Maxime Belanger, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 24719 open maxbelanger, 2021-03-03 08:22
Messages (5)
msg387965 - (view) Author: Maxime Belanger (Maxime Belanger) Date: 2021-03-02 20:42
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`.
msg398304 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-07-27 15:32
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.)
msg398320 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-27 21:22
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.
msg398355 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2021-07-28 08:24
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
msg398356 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-07-28 08:51
> 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!
History
Date User Action Args
2022-04-11 14:59:42adminsetgithub: 87543
2021-07-28 08:51:13pablogsalsetmessages: + msg398356
2021-07-28 08:24:50petr.viktorinsetmessages: + msg398355
2021-07-27 21:22:25pablogsalsetnosy: + pablogsal
messages: + msg398320
2021-07-27 15:32:06petr.viktorinsetnosy: + petr.viktorin
messages: + msg398304
2021-03-03 08:22:36maxbelangersetkeywords: + patch
nosy: + maxbelanger

pull_requests: + pull_request23495
stage: patch review
2021-03-02 20:42:17Maxime Belangercreate