Add escaping mode to PyUnicode_FromFormat(): %#c, %#s, %#S, %#U, %#V
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Feature or enhancement
Error messages often embed a C string or an object via the s, S, U and V conversions in PyUnicode_FromFormat() and PyErr_Format(). If the string contains non-printable characters, the message can be mangled or misleading: embedded newlines and terminal escape sequences break the output, invisible characters hide the actual content. The R and A conversions escape, but add surrounding quotes and require a Python object.
I propose to add an escaping mode, enabled by the # flag for the c, s, S, U and V conversions. It escapes special and non-printable characters like repr() does, but without adding quotes: \\, \t, \r and \n; other non-printable ASCII characters as \xNN; other non-printable characters as \uNNNN or \UNNNNNNNN. With the additional + flag (%+#s), all non-ASCII characters are escaped as well, so the result is pure ASCII.
For the s and V conversions, bytes which cannot be decoded from UTF-8 are escaped as \xNN, while valid non-ASCII characters are always escaped as \uNNNN or \UNNNNNNNN (e.g. \u009f for valid \xc2\x9f), so they can always be distinguished.
The precision is applied to the string before escaping, the width -- after escaping.
Quotes are deliberately not escaped: the escaped string is intended to be embedded into a larger message without quotes. For quoted output use the R and A conversions.
Related: gh-154610 (escaping attribute names in AttributeError messages).
Linked PRs
- gh-154669
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the named PyUnicode_FromFormat() and PyErr_Format() entry points, then compare the existing R and A conversions and related gh-154610 issue. Work is already linked to gh-154669, so review that instead of starting independently; done criteria include the specified # and + escaping and precision-before-escaping and width-after-escaping rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, python
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100