Zusammenfassung

Dieser PEP schlägt vor, die eingebaute Funktion str() zu ändern, damit sie Unicode-Strings zurückgeben kann. Diese Änderung würde es einfacher machen, Code zu schreiben, der mit beiden String-Typen funktioniert, und würde auch einigen bestehenden Code dazu bringen, Unicode-Strings zu verarbeiten. Die C-Funktion PyObject_Str() bliebe unverändert und stattdessen würde die Funktion PyString_New() hinzugefügt.

Begründung

Python hat seit einiger Zeit einen Unicode-String-Typ, aber seine Verwendung ist noch nicht weit verbreitet. Es gibt eine große Menge an Python-Code, der davon ausgeht, dass String-Daten als str-Instanzen repräsentiert werden. Der langfristige Plan für Python ist, den str-Typ auslaufen zu lassen und Unicode für alle String-Daten zu verwenden. Offensichtlich muss ein reibungsloser Migrationspfad bereitgestellt werden.

Wir müssen bestehende Bibliotheken, die für str-Instanzen geschrieben wurden, aufrüsten, um in einer Welt mit ausschließlich Unicode-Strings operieren zu können. Wir können nicht zu einer Welt mit ausschließlich Unicode übergehen, bis alle wesentlichen Bibliotheken dafür befähigt sind. Das Aufrüsten der Bibliotheken auf einmal erscheint nicht machbar. Eine realistischere Strategie ist es, die Bibliotheken einzeln befähigt zu machen, auf Unicode-Strings zu operieren und gleichzeitig ihr derzeitiges Verhalten in einer ausschließlich str-Umgebung zu bewahren.

Erstens müssen wir in der Lage sein, Code zu schreiben, der Unicode-Instanzen akzeptieren kann, ohne zu versuchen, sie in str-Instanzen umzuwandeln. Nennen wir solchen Code Unicode-sicher. Unicode-sichere Bibliotheken können in einer Welt mit ausschließlich Unicode verwendet werden.

Zweitens müssen wir in der Lage sein, Code zu schreiben, der, wenn er nur mit str-Instanzen versorgt wird, keine Unicode-Ergebnisse erzeugt. Nennen wir solchen Code str-stabil. Bibliotheken, die str-stabil sind, können von Bibliotheken und Anwendungen verwendet werden, die noch nicht Unicode-sicher sind.

Manchmal ist es einfach, Code zu schreiben, der sowohl str-stabil als auch Unicode-sicher ist. Zum Beispiel funktioniert die folgende Funktion einfach.

def appendx(s):
    return s + 'x'

Das ist nicht zu überraschend, da der Unicode-Typ dazu dient, die Aufgabe zu erleichtern. Das Prinzip ist, dass, wenn str- und Unicode-Instanzen aufeinandertreffen, das Ergebnis eine Unicode-Instanz ist. Eine bemerkenswerte Schwierigkeit entsteht, wenn Code eine String-Darstellung eines Objekts benötigt; eine Operation, die traditionell durch die Verwendung der eingebauten Funktion str() erreicht wird.

Die Verwendung der aktuellen str()-Funktion macht den Code nicht Unicode-sicher. Das Ersetzen eines str()-Aufrufs durch einen unicode()-Aufruf macht den Code nicht str-stabil. Das Ändern von str(), so dass es Unicode-Strings zurückgeben könnte, würde dieses Problem lösen. Als weiterer Vorteil würde einige Code, der derzeit nicht Unicode-sicher ist, weil er str() verwendet, Unicode-sicher werden.

Spezifikation

Eine Python-Implementierung der eingebauten Funktion str() folgt

def str(s):
    """Return a nice string representation of the object.  The
    return value is a str or unicode instance.
    """
    if type(s) is str or type(s) is unicode:
        return s
    r = s.__str__()
    if not isinstance(r, (str, unicode)):
        raise TypeError('__str__ returned non-string')
    return r

Die folgende Funktion würde zur C-API hinzugefügt und wäre das Äquivalent zur eingebauten Funktion str() (idealerweise würde sie PyObject_Str heißen, aber das Ändern dieser Funktion könnte eine riesige Anzahl von Kompatibilitätsproblemen verursachen)

PyObject *PyString_New(PyObject *);

Eine Referenzimplementierung ist auf Sourceforge [1] als Patch verfügbar.

Abwärtskompatibilität

Einige Code könnte erfordern, dass str() eine str-Instanz zurückgibt. In der Standardbibliothek wurde bisher nur ein solcher Fall gefunden. Die Funktion email.header_decode() erfordert eine str-Instanz und die Funktion email.Header.decode_header() versucht dies sicherzustellen, indem sie str() auf ihr Argument aufruft. Der Code wurde korrigiert, indem die Zeile "header = str(header)" geändert wurde zu

if isinstance(header, unicode):
    header = header.encode('ascii')

Ob dies wirklich ein Fehler ist, ist fraglich, da decode_header() wirklich auf Byte-Strings operiert, nicht auf Zeichen-Strings. Code, der ihr eine Unicode-Instanz übergibt, könnte selbst als fehlerhaft angesehen werden.

Alternative Lösungen

Eine neue eingebaute Funktion könnte anstelle der Änderung von str() hinzugefügt werden. Dies würde praktisch keine Rückwärtskompatibilitätsprobleme verursachen. Da die Kompatibilitätsprobleme jedoch voraussichtlich selten sein werden, erscheint die Änderung von str() der Hinzufügung einer neuen eingebauten Funktion vorzuziehen.

Der basestring-Typ könnte geändert werden, um das vorgeschlagene Verhalten zu haben, anstatt str() zu ändern. Dies wäre jedoch ein verwirrendes Verhalten für einen abstrakten Basistyp.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.