-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-126742: allow to use non-UTF8 exception messages #126746
base: main
Are you sure you want to change the base?
gh-126742: allow to use non-UTF8 exception messages #126746
Conversation
picnixz
commented
Nov 12, 2024
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Allow to set non-UTF8 exception messages #126742
Python/errors.c
Outdated
_PyErr_SetLocaleStringTstate(PyThreadState *tstate, PyObject *exception, | ||
const char *string) | ||
{ | ||
PyObject *value = PyUnicode_DecodeLocale(string, "strict"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be surrogateescape
, not strict
:
PyObject *value = PyUnicode_DecodeLocale(string, "strict"); | |
PyObject *value = PyUnicode_DecodeLocale(string, "surrogateescape"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both are acceptable and I think it's preferrable to use a strict decoding since a message that is not acceptable by the current locale feels wrong. In addition, using surrogateescape means that for re-encoding the message you need to also pass the "surrogateescape" handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, looking around, other usages in the context of error rendering use the "surrogateescape" handler, so I've decided to use it as well.
Technically, since this is a bugfix, let's wait until #126555 has landed before we merge this, and then address all the uses of |
I actually thought of doing it two PRs. Technically, this specific PR can be merged without waiting for the other and then you can use this interface in the other (rather the other way around). |
Eh, I would rather not. Let's not overwhelm someone with thread states and the private API on their first PR :) |
I've removed backport labels, per what Petr said in the issue. I think he's right--let's just focus on main with this. |