Zusammenfassung

Diese PEP schlägt vor, Nicht-ASCII-Buchstaben (wie z. B. Akzentbuchstaben, Kyrillisch, Griechisch, Kanji usw.) in Python-Bezeichnern zu unterstützen.

Begründung

Python-Code wird von vielen Menschen auf der ganzen Welt geschrieben, die mit der englischen Sprache nicht vertraut sind oder sich nicht gut mit dem lateinischen Schriftsystem auskennen. Solche Entwickler möchten oft Klassen und Funktionen mit Namen in ihrer Muttersprache definieren, anstatt sich eine (oft fehlerhafte) englische Übersetzung des Konzepts, das sie benennen möchten, ausdenken zu müssen. Durch die Verwendung von Bezeichnern in ihrer Muttersprache verbessern sich die Codeklarheit und die Wartbarkeit des Codes unter Sprechern dieser Sprache.

Für einige Sprachen existieren gängige Transliterationssysteme (insbesondere für lateinische Schriftsysteme). Für andere Sprachen haben Benutzer größere Schwierigkeiten, Latein zur Schreibweise ihrer Muttersprachwörter zu verwenden.

Häufige Einwände

Gegen Vorschläge wie diesen werden oft einige Einwände erhoben.

Die Leute behaupten, dass sie eine Bibliothek nicht verwenden können, wenn sie dafür Zeichen verwenden müssen, die sie nicht auf ihrer Tastatur eingeben können. Es liegt jedoch in der Wahl des Designers der Bibliothek, über verschiedene Einschränkungen bei der Verwendung der Bibliothek zu entscheiden: Die Leute können die Bibliothek möglicherweise nicht verwenden, weil sie keinen physischen Zugriff auf den Quellcode haben (weil er nicht veröffentlicht ist), oder weil die Lizenz die Nutzung verbietet, oder weil die Dokumentation in einer Sprache verfasst ist, die sie nicht verstehen. Ein Entwickler, der eine Bibliothek weit verbreiten möchte, muss eine Reihe expliziter Entscheidungen treffen (z. B. Veröffentlichung, Lizenzierung, Sprache der Dokumentation und Sprache der Bezeichner). Es sollte immer die Wahl des Autors sein, diese Entscheidungen zu treffen – nicht die Wahl der Sprachdesigner.

Insbesondere Projekte, die eine breite Nutzung wünschen, möchten wahrscheinlich eine Richtlinie festlegen, dass alle Bezeichner, Kommentare und Dokumentationen in englischer Sprache verfasst sind (siehe GNU Coding Style Guide als Beispiel für eine solche Richtlinie). Die Beschränkung der Sprache auf reine ASCII-Bezeichner erzwingt nicht, dass Kommentare und Dokumentationen auf Englisch verfasst werden, oder dass die Bezeichner tatsächlich englische Wörter sind. Daher ist ohnehin eine zusätzliche Richtlinie erforderlich.

Spezifikation von Sprachänderungen

Die Syntax von Bezeichnern in Python basiert auf dem Unicode-Standard-Annex UAX-31, mit Ausarbeitungen und Änderungen wie unten definiert.

Innerhalb des ASCII-Bereichs (U+0001..U+007F) sind die gültigen Zeichen für Bezeichner dieselben wie in Python 2.5. Diese Spezifikation führt nur zusätzliche Zeichen außerhalb des ASCII-Bereichs ein. Für andere Zeichen verwendet die Klassifizierung die Version der Unicode Character Database, wie sie im Modul unicodedata enthalten ist.

Die Bezeichnersyntax ist <XID_Start> <XID_Continue>*.

Die genaue Spezifikation, welche Zeichen die Eigenschaften XID_Start oder XID_Continue haben, findet sich in der Datei DerivedCoreProperties der von Python verwendeten Unicode-Daten (4.1 zum Zeitpunkt der Erstellung dieser PEP). Zum Referenzzwecke sind die Konstruktionsregeln für diese Mengen unten aufgeführt. Die XID_* Eigenschaften leiten sich von ID_Start/ID_Continue ab, die sich selbst ableiten.

ID_Start sind alle Zeichen, die eine der allgemeinen Kategorien Großbuchstaben (Lu), Kleinbuchstaben (Ll), Titelbuchstaben (Lt), Modifikatorbuchstaben (Lm), andere Buchstaben (Lo), Zahlbuchstaben (Nl), den Unterstrich und Zeichen mit der Eigenschaft Other_ID_Start haben. XID_Start schließt dann diese Menge unter Normalisierung, indem alle Zeichen entfernt werden, deren NFKC-Normalisierung nicht mehr die Form ID_Start ID_Continue* hat.

ID_Continue sind alle Zeichen in ID_Start, plus nicht-abstandshaltende Zeichen (Mn), abstandshaltende kombinierende Zeichen (Mc), Dezimalzahlen (Nd), Verbindungspunkte (Pc) und Zeichen mit der Eigenschaft Other_ID_Continue. Wiederum schließt XID_Continue diese Menge unter NFKC-Normalisierung; es fügt auch U+00B7 hinzu, um Katalanisch zu unterstützen.

Alle Bezeichner werden beim Parsen in die Normalform NFKC konvertiert; der Vergleich von Bezeichnern basiert auf NFKC.

Eine nicht-normative HTML-Datei mit allen gültigen Bezeichnerzeichen für Unicode 4.1 finden Sie unter https://web.archive.org/web/20081016132748/http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.

Richtlinienspezifikation

Als Ergänzung zum Python Coding Style wird folgende Richtlinie vorgeschrieben: Alle Bezeichner in der Python-Standardbibliothek MÜSSEN reine ASCII-Bezeichner verwenden und SOLLTEN möglichst englische Wörter verwenden (in vielen Fällen werden Abkürzungen und Fachbegriffe verwendet, die nicht englisch sind). Darüber hinaus müssen auch Zeichenkettenliterale und Kommentare in ASCII verfasst sein. Die einzigen Ausnahmen sind (a) Testfälle, die die Nicht-ASCII-Funktionen testen, und (b) Namen von Autoren. Autoren, deren Namen nicht auf dem lateinischen Alphabet basieren, MÜSSEN eine lateinische Transliteration ihrer Namen angeben.

Als Option kann diese Spezifikation auf Python 2.x angewendet werden. In diesem Fall würden reine ASCII-Bezeichner weiterhin als Byte-String-Objekte in Namespace-Wörterbüchern dargestellt; Bezeichner mit Nicht-ASCII-Zeichen würden als Unicode-Strings dargestellt.

Implementierung

Folgende Änderungen müssen am Parser vorgenommen werden

1. Wenn ein Nicht-ASCII-Zeichen in der UTF-8-Darstellung des Quellcodes gefunden wird, wird ein Vorwärts-Scan durchgeführt, um das erste ASCII-Nicht-Bezeichner-Zeichen (z. B. ein Leerzeichen oder ein Satzzeichen) zu finden.
2. Der gesamte UTF-8-String wird an eine Funktion übergeben, um den String nach NFKC zu normalisieren und dann zu überprüfen, ob er der Bezeichnersyntax entspricht. Kein solcher Aufruf erfolgt für reine ASCII-Bezeichner, die weiterhin wie bisher geparst werden. Die Unicode-Datenbank muss mit der Eigenschaft Other_ID_{Start|Continue} beginnen.
3. Wenn diese Spezifikation für 2.x implementiert wird, müssen reflektierende Bibliotheken (wie z. B. pydoc) verifiziert werden, um sicherzustellen, dass sie weiterhin funktionieren, wenn Unicode-Strings als Schlüssel in __dict__-Slots erscheinen.

Offene Fragen

John Nagle schlug die Berücksichtigung von Unicode Technical Standard #39 vor, der Sicherheitsmechanismen für Unicode-Bezeichner behandelt. Es ist nicht klar, wie dies genau auf diese PEP angewendet werden kann; mögliche Folgen sind

• Warnung vor Zeichen, die in xidmodifications.txt als „eingeschränkt“ aufgeführt sind
• Warnung vor Bezeichnern, die gemischte Skripte verwenden
• auf irgendeine Weise eine Verwechslungserkennung durchführen

Bei den letzteren beiden Ansätzen ist nicht klar, wie genau der Algorithmus funktionieren sollte. Bei gemischten Skripten sollten bestimmte Arten von Mischungen wahrscheinlich erlaubt sein – sind dies die „gemeinsamen“ und „vererbten“ Skripte, die in Abschnitt 5 erwähnt werden? Bei der Verwechslungserkennung scheint man zwei Bezeichner zum Vergleich auf Verwechslung zu benötigen – ist es möglich, sie irgendwie nur auf einen einzelnen Bezeichner anzuwenden und zu warnen?

In der nachfolgenden Diskussion stellt sich heraus, dass John Nagle eigentlich UTR#36, Level „Highly Restrictive“ vorschlagen wollte.

Mehrere Personen schlugen vor, Formatierungssteuerzeichen (allgemeine Kategorie Cf) zuzulassen und zu ignorieren, wie es in Java, JavaScript und C# geschieht. Es ist nicht klar, ob dies die Dinge verbessern würde (es könnte für RTL-Sprachen nützlich sein); falls Bedarf besteht, können diese später hinzugefügt werden.

Einige Leute möchten eine Option zur Laufzeit zur Auswahl der Unterstützung für diese PEP sehen; die Meinungen variieren darüber, was genau diese Option sein sollte und was genau ihr Standardwert sein sollte. Guido van Rossum kommentierte, dass ein globaler Schalter, der an den Interpreter übergeben wird, nicht akzeptabel sei, da er für alle Module gelten würde.

Diskussion

Ka-Ping Yee fasst die Diskussion und weitere Einwände zusammen wie folgt:

1. Sollen Bezeichner beliebige Unicode-Buchstaben enthalten dürfen?

   Nachteile der pauschalen Zulassung von Nicht-ASCII-Bezeichnern

   1. Python verliert die Fähigkeit, eine zuverlässige Hin- und Rückreise zu einer menschenlesbaren Anzeige auf dem Bildschirm oder auf Papier zu ermöglichen.
   2. Python wird anfällig für eine neue Klasse von Sicherheitsschwachstellen; Code und eingereichte Patches werden viel schwieriger zu inspizieren sein.
   3. Menschen werden die Python-Syntax nicht mehr validieren können.
   4. Unicode ist jung; seine Probleme sind noch nicht gut verstanden und gelöst; Tool-Unterstützung ist schwach.
   5. Sprachen mit Nicht-ASCII-Bezeichnern verwenden unterschiedliche Zeichensätze und Normalisierungsschemata; die Wahl von PEP 3131 ist nicht offensichtlich.
   6. Der Unicode-Bidi-Algorithmus liefert eine extrem verwirrende Anzeigereihenfolge für RTL-Text, wenn Ziffern oder Operatoren in der Nähe sind.
2. Sollte das Standardverhalten nur ASCII-Bezeichner akzeptieren oder Bezeichner mit Nicht-ASCII-Zeichen akzeptieren?

   Argumente für ASCII nur als Standard

   1. Nicht-ASCII-Bezeichner als Standard machen gängige Praktiken/Annahmen subtil/unwissentlich falsch; selten falsch ist schlimmer als offensichtlich falsch.
   2. Es ist besser, eine Warnung auszugeben, als stillschweigend zu fehlschlagen, wenn eine wahrscheinlich unerwartete Situation auftritt.
   3. Die gesamte aktuelle Nutzung ist reine ASCII-Nutzung; die überwiegende Mehrheit der zukünftigen Nutzung wird reine ASCII-Nutzung sein.
   3. Es sind die Nischen der Unicode-Annahme, die provinziel sind, nicht die ASCII-Befürworter.
   4. Python sollte reine ASCII-Bezeichner auf die gleiche Weise prüfen, wie es auf Tabulator-Leerzeichen-Konsistenz prüft.
   5. Inkrementelle Änderungen sind sicherer.
   6. Ein reiner ASCII-Standard bevorzugt die Open-Source-Entwicklung und den Austausch von Quellcode.
   7. Bestehende Projekte müssen keine Denkzeit verschwenden, um sich über die Auswirkungen von Unicode-Bezeichnern Gedanken zu machen.
3. Sollen Nicht-ASCII-Bezeichner optional sein?

   Verschiedene Stimmen unterstützen einen Schalter (obwohl es Debatten gab, welcher der Standard sein sollte, scheint niemand zu sagen, dass es keinen Aus-Schalter geben sollte).

4. Sollte der Bezeichner-Zeichensatz konfigurierbar sein?

   Verschiedene Stimmen schlagen einen wählbaren Zeichensatz vor und unterstützen ihn, damit Benutzer alle Vorteile der Verwendung ihrer eigenen Sprache ohne die Nachteile von verwechselbaren/unbekannten Zeichen erhalten.

5. Welche Bezeichnerzeichen sollten zulässig sein?
   1. Was ist mit Bidi-Formatierungssteuerzeichen?
   2. Was ist mit anderen ID_Continue-Zeichen? Was ist mit Zeichen, die wie Satzzeichen aussehen? Was ist mit anderen Empfehlungen in UTS #39? Was ist mit Bezeichnern mit gemischten Skripten?
6. Welche Normalisierungsform sollte verwendet werden, NFC oder NFKC?
7. Sollte der Quellcode in normalisierter Form sein müssen?

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.