Zusammenfassung

Der interne Darstellungstyp für Unicode-Strings wird geändert, um mehrere interne Darstellungen zu unterstützen, abhängig von dem Zeichen mit der größten Unicode-Ordnungszahl (1, 2 oder 4 Bytes). Dies ermöglicht eine speichereffiziente Darstellung in gängigen Fällen, erlaubt aber den Zugriff auf volles UCS-4 auf allen Systemen. Zur Kompatibilität mit bestehenden APIs können mehrere Darstellungen parallel existieren; mit der Zeit sollte diese Kompatibilität auslaufen. Die Unterscheidung zwischen schmalen und breiten Unicode-Builds wird aufgehoben. Eine Implementierung dieses PEP ist verfügbar unter [1].

Begründung

Es gibt zwei Arten von Beschwerden über die aktuelle Implementierung des Unicode-Typs: Auf Systemen, die nur UTF-16 unterstützen, beschweren sich Benutzer, dass Nicht-BMP-Zeichen nicht richtig unterstützt werden. Auf Systemen, die intern UCS-4 verwenden (und manchmal auch auf Systemen, die UCS-2 verwenden), gibt es die Beschwerde, dass Unicode-Strings zu viel Speicher verbrauchen – insbesondere im Vergleich zu Python 2.x, wo derselbe Code oft ASCII-Strings (d.h. ASCII-kodierte Byte-Strings) verwendet hätte. Mit dem vorgeschlagenen Ansatz werden reine ASCII-Unicode-Strings wieder nur ein Byte pro Zeichen verbrauchen; gleichzeitig wird weiterhin ein effizientes Indizieren von Strings ermöglicht, die Nicht-BMP-Zeichen enthalten (da Strings, die diese enthalten, 4 Bytes pro Zeichen verwenden werden).

Ein Problem des Ansatzes ist die Unterstützung bestehender Anwendungen (z. B. Erweiterungsmodule). Zur Kompatibilität können redundante Darstellungen berechnet werden. Anwendungen werden ermutigt, die Abhängigkeit von einer bestimmten internen Darstellung, wenn möglich, auslaufen zu lassen. Da die Interaktion mit anderen Bibliotheken oft eine Art interner Darstellung erfordert, wählt die Spezifikation UTF-8 als empfohlene Methode, um Strings für C-Code bereitzustellen.

Für viele Strings (z. B. ASCII) können mehrere Darstellungen tatsächlich Speicher teilen (z. B. kann die kürzeste Form mit der UTF-8-Form geteilt werden, wenn alle Zeichen ASCII sind). Mit solchem Teilen wird der Overhead von Kompatibilitätsdarstellungen reduziert. Wenn Darstellungen Daten teilen, ist es auch möglich, Strukturfelder wegzulassen, wodurch die Basisgröße von String-Objekten reduziert wird.

Spezifikation

Unicode-Strukturen sind nun als Hierarchie von Strukturen definiert, nämlich

typedef struct {
  PyObject_HEAD
  Py_ssize_t length;
  Py_hash_t hash;
  struct {
      unsigned int interned:2;
      unsigned int kind:2;
      unsigned int compact:1;
      unsigned int ascii:1;
      unsigned int ready:1;
  } state;
  wchar_t *wstr;
} PyASCIIObject;

typedef struct {
  PyASCIIObject _base;
  Py_ssize_t utf8_length;
  char *utf8;
  Py_ssize_t wstr_length;
} PyCompactUnicodeObject;

typedef struct {
  PyCompactUnicodeObject _base;
  union {
      void *any;
      Py_UCS1 *latin1;
      Py_UCS2 *ucs2;
      Py_UCS4 *ucs4;
  } data;
} PyUnicodeObject;

Objekte, für die sowohl die Größe als auch das maximale Zeichen zur Erstellungszeit bekannt sind, werden als „kompakte“ Unicode-Objekte bezeichnet; die Zeichendaten folgen unmittelbar der Basisstruktur. Wenn das maximale Zeichen kleiner als 128 ist, verwenden sie die Struktur PyASCIIObject, und die UTF-8-Daten, die UTF-8-Länge und die wstr-Länge sind gleich der Länge der ASCII-Daten. Für Nicht-ASCII-Strings wird die Struktur PyCompactObject verwendet. Das Ändern der Größe von kompakten Objekten wird nicht unterstützt.

Objekte, für die das maximale Zeichen nicht zur Erstellungszeit angegeben wird, werden als „Legacy“-Objekte bezeichnet und durch PyUnicode_FromStringAndSize(NULL, length) erstellt. Sie verwenden die Struktur PyUnicodeObject. Anfangs sind ihre Daten nur im wstr-Zeiger enthalten; wenn PyUnicode_READY aufgerufen wird, wird der Datenzeiger (Union) zugewiesen. Eine Größenänderung ist möglich, solange PyUnicode_READY nicht aufgerufen wurde.

Die Felder haben folgende Interpretationen:

• length: Anzahl der Code Points im String (Ergebnis von sq_length)
• interned: Internierungsstatus (SSTATE_*) wie in 3.2
• kind: Form des Strings
  • 00 => str ist nicht initialisiert (Daten sind in wstr)
  • 01 => 1 Byte (Latin-1)
  • 10 => 2 Bytes (UCS-2)
  • 11 => 4 Bytes (UCS-4);
• compact: Das Objekt verwendet eine der kompakten Darstellungen (impliziert ready)
• ascii: Das Objekt verwendet die PyASCIIObject-Darstellung (impliziert compact und ready)
• ready: Die kanonische Darstellung ist zur Verfügung gestellt unter PyUnicode_DATA und PyUnicode_GET_LENGTH. Dies wird entweder gesetzt, wenn das Objekt kompakt ist, oder wenn der Datenzeiger und die Länge initialisiert wurden.
• wstr_length, wstr: Darstellung in der plattformabhängigen wchar_t (null-terminiert). Wenn wchar_t 16-Bit ist, kann diese Form Ersatzpaare verwenden (in diesem Fall unterscheidet sich wstr_length von length). wstr_length unterscheidet sich von length nur, wenn Ersatzpaare in der Darstellung vorhanden sind.
• utf8_length, utf8: UTF-8-Darstellung (null-terminiert).
• data: Darstellung des Unicode-Strings in der kürzesten Form. Der String ist null-terminiert (in seiner jeweiligen Darstellung).

Alle drei Darstellungen sind optional, obwohl die Datenform als kanonische Darstellung gilt, die nur während der Erstellung des Strings abwesend sein kann. Wenn die Darstellung fehlt, ist der Zeiger NULL und das entsprechende Längenfeld kann beliebige Daten enthalten.

Der Typ Py_UNICODE wird weiterhin unterstützt, ist aber veraltet. Er wird immer als Typedef für wchar_t definiert, sodass die wstr-Darstellung als Py_UNICODE-Darstellung verwendet werden kann.

Die Zeiger data und utf8 zeigen auf denselben Speicher, wenn der String nur ASCII-Zeichen verwendet (nur Latin-1 reicht nicht aus). Die Zeiger data und wstr zeigen auf denselben Speicher, wenn der String genau in den wchar_t-Typ der Plattform passt (d.h., verwendet einige BMP-nicht-Latein-1-Zeichen, wenn sizeof(wchar_t) 2 ist, und verwendet einige Nicht-BMP-Zeichen, wenn sizeof(wchar_t) 4 ist).

PyObject* PyUnicode_New(Py_ssize_t size, Py_UCS4 maxchar);

Diskussion

Mehrere Bedenken wurden bezüglich des hier vorgestellten Ansatzes geäußert:

Er macht die Implementierung komplexer. Das stimmt, wird aber angesichts der Vorteile als lohnenswert erachtet.

Die Py_UNICODE-Darstellung ist nicht sofort verfügbar, was Anwendungen, die sie anfordern, verlangsamt. Das stimmt zwar auch, aber Anwendungen, denen dieses Problem wichtig ist, können umgeschrieben werden, um die Datenrepräsentation zu verwenden.

Portierungsrichtlinien

Nur ein kleiner Teil des C-Codes ist von diesem PEP betroffen, nämlich Code, der „in“ Unicode-Strings hineinschauen muss. Dieser Code muss nicht unbedingt auf diese API portiert werden, da die bestehende API weiterhin korrekt funktionieren wird. Insbesondere Module, die sowohl Python 2 als auch Python 3 unterstützen müssen, könnten zu kompliziert werden, wenn sie gleichzeitig diese neue API und die alte Unicode-API unterstützen.

Um Module auf die neue API zu portieren, versuchen Sie, die Verwendung dieser API-Elemente zu eliminieren:

• der Py_UNICODE-Typ,
• PyUnicode_AS_UNICODE und PyUnicode_AsUnicode,
• PyUnicode_GET_SIZE und PyUnicode_GetSize, und
• PyUnicode_FromUnicode.

Beim Iterieren über einen bestehenden String oder beim Betrachten spezifischer Zeichen verwenden Sie Indexierungsoperationen anstelle von Zeigerarithmetik; Indexierung funktioniert gut für PyUnicode_READ(_CHAR) und PyUnicode_WRITE. Verwenden Sie void* als Puffertyp für Zeichen, damit der Compiler ungültige Dereferenzierungsoperationen erkennt. Wenn Sie Zeigerarithmetik verwenden möchten (z. B. beim Konvertieren von bestehendem Code), verwenden Sie (unsigned) char* als Puffertyp und halten Sie die Elementgröße (1, 2 oder 4) in einer Variablen. Beachten Sie, dass (1<<(kind-1)) die Elementgröße bei gegebenem Puffer-Kind ergibt.

Beim Erstellen neuer Strings war es in Python üblich, mit einer heuristischen Puffergröße zu beginnen und dann zu vergrößern oder zu verkleinern, wenn die Heuristiken fehlschlugen. Mit diesem PEP ist dies nun weniger praktikabel, da Sie nicht nur eine Heuristik für die Länge des Strings, sondern auch für das maximale Zeichen benötigen.

Um Heuristiken zu vermeiden, müssen Sie den Input zweimal durchlaufen: einmal, um die Ausgabelänge und das maximale Zeichen zu bestimmen; dann den Zielstring mit PyUnicode_New zuweisen und den Input ein zweites Mal durchlaufen, um die endgültige Ausgabe zu erzeugen. Das mag zwar aufwendig klingen, kann aber tatsächlich günstiger sein, als das Ergebnis erneut kopieren zu müssen, wie im folgenden Ansatz.

Wenn Sie den heuristischen Weg wählen, vermeiden Sie die Zuweisung eines Strings, der für die Größenänderung vorgesehen ist, da die Größenänderung von Strings für ihre kanonische Darstellung nicht funktioniert. Weisen Sie stattdessen einen separaten Puffer zu, um die Zeichen zu sammeln, und erstellen Sie dann ein Unicode-Objekt daraus mit PyUnicode_FromKindAndData. Eine Möglichkeit ist die Verwendung von Py_UCS4 als Pufferelement, unter Annahme des schlimmsten Falls bei Zeichenordnungen. Dies ermöglicht Zeigerarithmetik, kann aber viel Speicher benötigen. Alternativ beginnen Sie mit einem 1-Byte-Puffer und erhöhen Sie die Elementgröße, wenn Sie auf größere Zeichen stoßen. In jedem Fall durchsucht PyUnicode_FromKindAndData den Puffer, um das maximale Zeichen zu überprüfen.

Für gängige Aufgaben ist direkter Zugriff auf die String-Darstellung möglicherweise nicht notwendig: PyUnicode_Find, PyUnicode_FindChar, PyUnicode_Ord und PyUnicode_CopyCharacters helfen bei der Analyse und Erstellung von String-Objekten, die auf Indizes statt auf Datenzeigern operieren.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.