Hinweis

Dies ist im Wesentlichen eine rückwirkende PEP: Das Problem trat im Release-Prozess von 2.1 zu spät auf, um eine breite Meinung einzuholen, bevor entschieden wurde, was zu tun ist, und kann nicht bis 2.2 verschoben werden, ohne auch die Cygwin- und MacOS X-Ports zu verzögern.

Motivation

Dateisysteme variieren zwischen Plattformen darin, ob sie die Groß-/Kleinschreibung von Dateinamen beibehalten oder nicht, und ob die plattformspezifischen C-Bibliotheksfunktionen zum Öffnen von Dateien case-sensitive Übereinstimmungen erzwingen oder nicht.

                     case-preserving     case-destroying
                 +-------------------+------------------+
case-sensitive   | most Unix flavors | brrrrrrrrrr      |
                 +-------------------+------------------+
case-insensitive | Windows           | some unfortunate |
                 | MacOSX HFS+       | network schemes  |
                 | Cygwin            |                  |
                 |                   | OpenVMS          |
                 +-------------------+------------------+

In der oberen linken Box wird beim Erstellen von „fiLe“ „fiLe“ gespeichert, und nur open("fiLe") öffnet es (open("file") nicht, ebenso wie die 14 anderen Variationen dieses Themas).

In der unteren rechten Box ist, wenn Sie „fiLe“ erstellen, nicht vorhersehbar, wie es gespeichert wird – aber höchstwahrscheinlich als „FILE“ – und jede der 16 offensichtlichen Variationen von open("FilE") öffnet es.

Die untere linke Box ist eine Mischung: Beim Erstellen von „fiLe“ wird „fiLe“ im Plattformverzeichnis gespeichert, aber Sie müssen die Groß-/Kleinschreibung beim Öffnen nicht beachten; jede der 16 offensichtlichen Variationen von open("FILe") funktioniert.

NICHTS DAVON WIRD GEÄNDERT! Python wird weiterhin die Plattformkonventionen in Bezug auf die Beibehaltung der Groß-/Kleinschreibung beim Erstellen einer Datei und in Bezug auf die Frage, ob open() eine case-sensitive Übereinstimmung erfordert, befolgen. In der Praxis sollten Sie immer so programmieren, als wären Übereinstimmungen case-sensitive, sonst ist Ihr Programm nicht portabel.

Vorgeschlagen wird, die Semantik von Python „import“-Anweisungen zu ändern, und das *nur* in der unteren linken Box.

Aktuelle Semantik der linken unteren Ecke

Unterstützung für MacOSX HFS+ und für Cygwin ist neu in 2.1, daher ändert sich dort nichts. Was sich ändert, ist das Verhalten unter Windows. Hier sind die aktuellen Regeln für den Import unter Windows

1. Obwohl das Dateisystem case-insensitiv ist, besteht Python auf einer case-sensitive Übereinstimmung. Aber nicht auf die Art und Weise, wie die obere linke Box funktioniert: Wenn Sie zwei Dateien haben, FiLe.py und file.py in sys.path, und tun

   import file
   

   dann, wenn Python zuerst FiLe.py findet, löst es einen NameError aus. Es fährt *nicht* fort, file.py zu finden; tatsächlich ist es unmöglich, einen anderen als den ersten case-insensitiven Treffer in sys.path zu importieren, und das nur, wenn die Groß-/Kleinschreibung im ersten case-insensitiven Treffer exakt übereinstimmt.

2. Eine hässliche Ausnahme: Wenn der erste case-insensitive Treffer in sys.path für eine Datei ist, deren Name vollständig in Großbuchstaben geschrieben ist (FILE.PY oder FILE.PYC oder FILE.PYO), dann greift der Import stillschweigend diese, unabhängig von der verwendeten Groß-/Kleinschreibung in der Importanweisung. Dies dient offenbar dazu, elende alte Dateisysteme zu berücksichtigen, die wirklich in die rechte untere Box passen. Aber diese Ausnahme ist einzigartig für Windows, aus Gründen, die existieren mögen oder auch nicht.
3. Und eine weitere Ausnahme: Wenn die Umgebungsvariable PYTHONCASEOK existiert, greift Python stillschweigend den ersten case-insensitiven Treffer beliebiger Art auf.

Diese Windows-Regeln sind also ziemlich kompliziert und entsprechen weder den Unix-Regeln noch bieten sie eine natürliche Semantik für das native Dateisystem. Das macht sie schwer zu erklären, egal ob für Unix-*oder* Windows-Benutzer. Dennoch haben sie jahrelang gut funktioniert, und isoliert betrachtet gibt es keinen zwingenden Grund, sie zu ändern.

Das war jedoch vor der Ankunft der MacOSX HFS+ und Cygwin-Ports. Diese haben ebenfalls case-preserving case-insensitive Dateisysteme, aber die Portierungsverantwortlichen verabscheuten die Windows-Regeln. Tatsächlich kam ein Patch, um HFS+ für Imports wie Unix agieren zu lassen, durch einen Gutachter und in die Codebasis, was zufällig auch Cygwin wie Unix agieren ließ (aber dies stieß auf grenzenlose Zustimmung der Cygwin-Leute, also beschwerten sie sich sicherlich nicht – sie hatten eigene Patches, um dies zu tun, aber der Gutachter für diese sträubte sich).

Auf einer höheren Ebene wollen wir Python konsistent halten, indem wir auf *allen* Plattformen mit case-preserving case-insensitive Dateisystemen die gleichen Regeln befolgen.

Proposed Semantics

Die vorgeschlagene neue Semantik für die untere linke Box

1. Wenn die Umgebungsvariable PYTHONCASEOK existiert, wie zuvor: akzeptiere stillschweigend den ersten case-insensitiven Treffer beliebiger Art; löse ImportError aus, wenn keiner gefunden wird.
2. Andernfalls durchsuche sys.path nach dem ersten case-sensitive Treffer; löse ImportError aus, wenn keiner gefunden wird.

#B ist die gleiche Regel wie unter Unix, daher wird dies die plattformübergreifende Portabilität verbessern. Das ist gut. #B ist auch die Regel, die die Mac- und Cygwin-Leute wollen (und wollten, genug, um sie selbst zu implementieren, mehrfach, was ein starkes Argument in PythonLand ist). Sie kann keinen bestehenden nicht-ausnahmshaften Windows-Import fehlschlagen lassen, da jeder bestehende nicht-ausnahmshafte Windows-Import zuerst einen case-sensitive Treffer im Pfad findet – und das wird er auch weiterhin tun. Ein ausnahmshafter Windows-Import schlägt derzeit mit einem NameError oder ImportError fehl, in letzterem Fall wird er immer noch fehlschlagen, oder im ersteren Fall wird die Suche fortgesetzt, und entweder erfolgreich sein oder mit einem ImportError fehlschlagen.

#A wird benötigt, um case-destroing Dateisysteme auf Windows zu berücksichtigen, und *könnte* auch von Leuten verwendet werden, die von dem „natürlichen“ Windows-Verhalten so begeistert sind, dass sie bereit sind, eine Umgebungsvariable zu setzen, um es zu bekommen. Ich beabsichtige nicht, #A auch für Unix zu implementieren, aber das liegt nur daran, dass ich nicht klar weiß, wie ich das effizient tun *könnte* (ich werde Imports unter Unix nicht verlangsamen, nur für theoretische Reinheit).

Der potenzielle Schaden liegt hier: #2 (Übereinstimmung mit ALLCAPS.PY) soll gestrichen werden. Case-destroing Dateisysteme sind eine aussterbende Art, und die Unterstützung dafür ist hässlich. Wir unterstützen bereits (und werden weiterhin) PYTHONCASEOK für deren Vorteile, aber sie verdienen im Jahr 2001 keine mehreren Hacks.