Skip to content

Remove references to Unicode objects being ready #130790

Closed

Description

@picnixz

We have some code referrencing readiness of Unicode objects but this property is deprecated (see #129894 (comment)). Following @encukou's advice, we should address each module with a separate PR so that experts can review them separately.

unicodedata.c

/* result is guaranteed to be ready, as it is compact. */
kind = PyUnicode_KIND(result);
data = PyUnicode_DATA(result);

result = nfd_nfkd(self, input, k);
if (!result)
return NULL;
/* result will be "ready". */
kind = PyUnicode_KIND(result);
data = PyUnicode_DATA(result);
len = PyUnicode_GET_LENGTH(result);

_io/textio.c

kind = PyUnicode_KIND(modified);
out = PyUnicode_DATA(modified);
PyUnicode_WRITE(kind, out, 0, '\r');
memcpy(out + kind, PyUnicode_DATA(output), kind * output_len);
Py_SETREF(output, modified); /* output remains ready */
self->pendingcr = 0;
output_len++;

cpython/Modules/_io/textio.c

Lines 1821 to 1824 in a85eeb9

/* decoded_chars is guaranteed to be "ready". */
avail = (PyUnicode_GET_LENGTH(self->decoded_chars)
- self->decoded_chars_used);

Parser files

/* Verify that the identifier follows PEP 3131.
All identifier strings are guaranteed to be "ready" unicode objects.
*/
static int
verify_identifier(struct tok_state *tok)

cpython/Parser/pegen.c

Lines 505 to 513 in a85eeb9

PyObject *
_PyPegen_new_identifier(Parser *p, const char *n)
{
PyObject *id = PyUnicode_DecodeUTF8(n, (Py_ssize_t)strlen(n), NULL);
if (!id) {
goto error;
}
/* PyUnicode_DecodeUTF8 should always return a ready string. */
assert(PyUnicode_IS_READY(id));

tracemalloc.c

if (!PyUnicode_IS_READY(filename)) {
/* Don't make a Unicode string ready to avoid reentrant calls
to tracemalloc_alloc() or tracemalloc_realloc() */
#ifdef TRACE_DEBUG
tracemalloc_error("filename is not a ready unicode string");
#endif
return;
}

This one seems to be dead code (cc @vstinner)

Linked PRs

Activity

  1. added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    type-bugAn unexpected behavior, bug, or error
    on Mar 3, 2025
  2. vstinner commented on Mar 3, 2025

    @vstinner
    Member

    If it's just a few lines in each C file, a single PR would be more convenient.

  3. sergey-miryanov commented on Mar 3, 2025

    @sergey-miryanov
    Contributor

    @picnixz Do you plan to work on this, or can I take it?

  4. picnixz commented on Mar 3, 2025

    @picnixz
    MemberAuthor

    I was planning to do it tomorrow, but feel free to take it. It's just that I don't know if we need to split into multiple PRs or in one. I haven't looked at the code exactly to see whether we can safely remove the comment/code so there might be some conditions that still need to be checked.

  5. sergey-miryanov commented on Mar 3, 2025

    @sergey-miryanov
    Contributor

    @picnixz I allowed a little bit more to myself and updated the comments to public API. Is this ok?

  6. added
    type-featureA feature request or enhancement
    and removed
    type-bugAn unexpected behavior, bug, or error
    on Mar 3, 2025
  7. added a commit that references this issue on Mar 3, 2025
  8. hugovk commented on Mar 17, 2025

    @hugovk
    Member

    Triage: looks like all done here? Please re-open if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions