PEP 686 - UTF-8-Modus als Standardeinstellung

PEP 686 - Ab Python 3.15 ist der UTF-8-Modus standardmäßig aktiviert

• UTF-8 wird de facto zum Standard für Textkodierung
  • Die Standardkodierung von Python-Quelldateien ist UTF-8
  • JSON, TOML und YAML verwenden UTF-8
  • Die meisten Texteditoren wie Visual Studio Code und Windows-Editor verwenden standardmäßig UTF-8
  • Die meisten Websites und Textdaten im Internet verwenden UTF-8
  • Viele andere populäre Programmiersprachen wie Node.js, Go, Rust und Java verwenden ebenfalls standardmäßig UTF-8
• Wenn die Standardkodierung auf UTF-8 umgestellt wird, kann Python leichter mit anderen Sprachen zusammenarbeiten
• Viele Python-Entwickler auf Unix vergessen, dass sich die Standardkodierung je nach Plattform unterscheidet
  • Beim Lesen von UTF-8-kodierten Textdateien (JSON, TOML, Markdown, Python-Quelldateien usw.) wird encoding="utf-8" nicht angegeben
  • Durch uneinheitliche Standardkodierungen entstehen viele Bugs

Wichtige Änderungen in PEP 686

• Ab Python 3.15 ist der UTF-8-Modus standardmäßig aktiviert
  • Benutzer können den UTF-8-Modus weiterhin mit PYTHONUTF8=0 oder -X utf8=0 deaktivieren
• locale.getencoding() hinzugefügt
  • Eine API, um die Locale-Kodierung unabhängig vom UTF-8-Modus zu erhalten
  • Wenn die Option warn_default_encoding angegeben ist, löst locale.getpreferredencoding() wie open() eine EncodingWarning aus (siehe PEP 597)
• Anpassung der Option encoding="locale"
  • TextIOWrapper soll bei angegebenem encoding="locale" auch im UTF-8-Modus die Locale-Kodierung verwenden

Abwärtskompatibilität

• Da die meisten Unix-Systeme UTF-8-Locale verwenden und Python den UTF-8-Modus aktiviert, wenn die Locale C oder POSIX ist, betrifft diese Änderung hauptsächlich Windows-Benutzer
• Wenn ein Python-Programm von der Standardkodierung abhängt, kann diese Änderung UnicodeError, Mojibake oder stille Datenbeschädigung verursachen
• Leitfaden zur Behebung von Abwärtskompatibilitätsproblemen:
  1. UTF-8-Modus deaktivieren
  2. Mit EncodingWarning (PEP 597) alle Stellen finden, die vom UTF-8-Modus beeinflusst werden
     • Wenn die Option encoding weggelassen wurde, die Verwendung von encoding="utf-8" oder encoding="locale" in Betracht ziehen
     • Wenn locale.getpreferredencoding() verwendet wird, die Verwendung von "utf-8" oder locale.getencoding() in Betracht ziehen
  3. Anwendung im UTF-8-Modus testen

Meinung von GN⁺

• Dieses PEP zielt darauf ab, die Standardkodierung von Python auf UTF-8 zu vereinheitlichen und damit die Interoperabilität mit anderen Sprachen und Systemen zu verbessern. Das dürfte dazu beitragen, dass Python in globalen Entwicklungsumgebungen noch reibungsloser eingesetzt werden kann
• Diese Änderung kann jedoch die Abwärtskompatibilität bestehender Python-Programme beeinträchtigen. Besonders bei Programmen, die in Windows-Umgebungen laufen, ist Vorsicht geboten
• Entwickler sollten EncodingWarning nutzen, um betroffene Stellen zu identifizieren, und mit Maßnahmen wie der expliziten Angabe der Option encoding darauf reagieren
• Langfristig dürfte diese Änderung positive Auswirkungen auf das Python-Ökosystem haben. Kurzfristig können in einigen Projekten jedoch Migrationskosten entstehen
• Entwickler sollten diese Änderung bei der Planung eines Upgrades auf Python 3.15 berücksichtigen und bei Bedarf geeignete Maßnahmen für die Abwärtskompatibilität ergreifen

[GN⁺]

Hacker-News-Kommentar

• Dass die Standard-Textdatei-Codierung von Python je nach Plattform unterschiedlich ist, war lange ein Problem
• Das Dateisystem-Codierungsproblem ist ein separates Thema und wird durch diese Änderung nicht behandelt
• Sich auf System-Defaults zu verlassen, ist keine gute Idee, weil sie von den Annahmen abweichen können
• Früher gab es Probleme mit Ubuntu und init.d-Skripten. Ein als Root ausgeführtes Java-Startskript verwendete eine andere Codierung als normale Benutzer, was Probleme verursachte
• Heutzutage ist das seltener ein Problem, aber man sollte das nicht dem OS überlassen. Die Verwendung anderer Codierungen als UTF-8 ist wahrscheinlich unbeabsichtigt
• Es ist keine gute Idee, nichts explizit anzugeben und sich auf die OS-Einstellungen zu verlassen
• Diese Änderung geht in die richtige Richtung. Code, der dadurch kaputtgeht, sollte man lieber einfach korrigieren
• Das ist besser, als es in einem Zustand mit möglichem Datenkorruptions-Bug zu belassen

Eine Faustregel, die in den letzten Jahrzehnten immer mehr zur Realität geworden ist: Wenn die Einstellung für den "charset" nicht UTF-8 ist, dann ist sie falsch

• Python 2 war gegenüber Charsets gleichgültig und funktionierte deshalb immer problemlos, aber die Verbesserungen in Python 3 waren mehr als nur Verbesserungen

• So kann man Python-3-Skripte von Python-2-Skripten unterscheiden:

  • Wenn der String "utf-8" vorkommt, ist es Python 3
  • Wenn es nur im C.UTF-8-Locale funktioniert, ist es Python 3

• Diese Änderung ist zu begrüßen und scheint Python 3 weiter zu "verbessern"

• Ich dachte, das sei seit Python 3 bereits der Standard

Viele populäre Sprachen, darunter Node.js, Go, Rust und Java, verwenden standardmäßig UTF-8

• Ich wusste nicht, dass Java von UTF-16 auf UTF-8 umgestiegen ist

• Ich weiß nicht, ob die interne Codierung von CPython UTF-8 ist

• Python-Strings sind indizierbar, aber Random Access ist selten, daher wäre verzögerte Indexierung bei Bedarf vermutlich sinnvoll

• Wenn man sich nur Zeichen für Zeichen vorwärts oder rückwärts bewegt, braucht man keinen Index

• Daher scheint eine interne UTF-8-Repräsentation möglich zu sein

• Warum nicht utf-8-sig? Das ist nützlich, weil es ein BOM optional verarbeiten kann

• Im Zusammenhang mit UTF-8 hätte der Linux-Framebuffer eigentlich schon vor langer Zeit ordentliche UTF-8-Unterstützung haben sollen

• GNU Hurd hatte etwa seit 2007 eine bessere "terminal console" mit UTF-8-Unterstützung

• Kaum zu glauben, dass so eine Änderung erst jetzt, im Jahr 2024, kommt

• Gute Änderung. Jetzt müsste nur noch JS auf UTF-8 umgestellt werden, aber Verbesserungen sind schwierig, weil Kompatibilität mit Code aus dem Jahr 1995 erhalten bleiben muss

Viele Unix-Python-Entwickler vergessen, dass die Standard-Codierung je nach Plattform unterschiedlich ist, und geben beim Lesen von UTF-8-Textdateien encoding="utf-8" nicht explizit an

• Eher als "vergessen" scheint es, als sei ihnen das gar nicht richtig bewusst
• Ich dachte, Python würde überall einfach UTF-8 verwenden, solange man nicht explizit etwas anderes anfordert