python / python/cpython

C API: Soft deprecate functions modifying str objects (PyUnicodeObject)

Ouverte
#157,710 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

interpreter-core topic-C-API type-feature
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

Description

Python 3.14 added PyUnicodeWriter C API which is a safe way to create a Unicode object. IMO it's now time to soft deprecate the legacy way to create a str object using PyUnicode_New(): deprecate functions like PyUnicode_CopyCharacters() and PyUnicode_Resize().

The PyUnicode_New() API is more fragile. It's possible that a str object is "used" before it's fully initialized, which make following functions (modifying the str) fail or crash. It can also be exposed in Python by mistake before it's fully initialized.

PyUnicodeWriter has a different design than PyUnicode_New(): it's designed to append multiple strings, whereas PyUnicode_New() gives a direct access to an array of characters in a specific format (Py_UCS1, Py_UCS2 or Py_UCS4: 1, 2 or 4 bytes per character).

If PyUnicodeWriter doesn't fit well with existing code, it's possible to allocate an array of characters, write into this array, and then call PyUnicode_FromKindAndData() to create a str object.

Another option is to create a UTF-8 encode string and then call PyUnicode_FromString().

Linked PRs
  • gh-157711
  • gh-157712
  • gh-157715

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Examinez d’abord les PR liés gh-157711, gh-157712 et gh-157715, puis inspectez les points d’entrée de la C API PyUnicode_New(), PyUnicode_CopyCharacters() et PyUnicode_Resize(). Le travail est considéré comme terminé lorsqu’un accord a été trouvé sur les fonctions legacy qui doivent faire l’objet d’un traitement de soft-deprecation et que le comportement résultant de l’API a été documenté ou testé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
c, python
Domaine
api
Type d'issue
Refactorisation
Difficulté
4/5
Temps estimé
3-5 jours
Activité
À l'abandon
Clarté
Plutôt claire
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.