Beispiele

Wie würde das in der Praxis aussehen?

Nehmen wir an, wir haben ein Python-Paket namens alpha, das ein Unterpaket namens beta enthält. Das Quellverzeichnislayout vor der Byte-Kompilierung könnte wie folgt aussehen:

alpha/
    __init__.py
    one.py
    two.py
    beta/
        __init__.py
        three.py
        four.py

Nachdem dieses Paket mit Python 3.2 Byte-kompiliert wurde, würde das folgende Layout angezeigt werden:

alpha/
    __pycache__/
        __init__.cpython-32.pyc
        one.cpython-32.pyc
        two.cpython-32.pyc
    __init__.py
    one.py
    two.py
    beta/
        __pycache__/
            __init__.cpython-32.pyc
            three.cpython-32.pyc
            four.cpython-32.pyc
        __init__.py
        three.py
        four.py

Hinweis: Die Reihenfolge der Auflistung kann je nach Plattform variieren.

Nehmen wir an, zwei neue Python-Versionen werden installiert, eine ist Python 3.3 und die andere ist Unladen Swallow. Nach der Byte-Kompilierung würde das Dateisystem wie folgt aussehen:

alpha/
    __pycache__/
        __init__.cpython-32.pyc
        __init__.cpython-33.pyc
        __init__.unladen-10.pyc
        one.cpython-32.pyc
        one.cpython-33.pyc
        one.unladen-10.pyc
        two.cpython-32.pyc
        two.cpython-33.pyc
        two.unladen-10.pyc
    __init__.py
    one.py
    two.py
    beta/
        __pycache__/
            __init__.cpython-32.pyc
            __init__.cpython-33.pyc
            __init__.unladen-10.pyc
            three.cpython-32.pyc
            three.cpython-33.pyc
            three.unladen-10.pyc
            four.cpython-32.pyc
            four.cpython-33.pyc
            four.unladen-10.pyc
        __init__.py
        three.py
        four.py

Wie Sie sehen können, können beliebig viele pyc-Dateien nebeneinander existieren, solange die Python-Versionsidentifizierungszeichenkette eindeutig ist. Diese Identifizierungszeichenketten werden unten näher erläutert.

Eine angenehme Eigenschaft dieses Layouts ist, dass die __pycache__-Verzeichnisse generell ignoriert werden können, sodass eine normale Verzeichnislistung etwa so aussehen würde:

alpha/
    __pycache__/
    __init__.py
    one.py
    two.py
    beta/
        __pycache__/
        __init__.py
        three.py
        four.py

Dies ist viel weniger unübersichtlich als selbst das heutige Python.

Fall 0: Der stationäre Zustand

Wenn Python aufgefordert wird, das Modul foo zu importieren, sucht es entlang seines sys.path nach einer foo.py-Datei (oder einem foo-Paket, aber das ist für diese Diskussion nicht wichtig). Wenn gefunden, prüft Python, ob eine übereinstimmende __pycache__/foo.<magic>.pyc-Datei vorhanden ist, und wenn ja, wird diese pyc-Datei geladen.

Fall 1: Der erste Import

Wenn Python die foo.py-Datei findet, und die __pycache__/foo.<magic>.pyc-Datei fehlt, wird Python diese erstellen und bei Bedarf auch das __pycache__-Verzeichnis erstellen. Python wird die foo.py-Datei parsen und byte-kompilieren und den Bytecode in __pycache__/foo.<magic>.pyc speichern.

Fall 2: Der zweite Import

Wenn Python aufgefordert wird, das Modul foo ein zweites Mal zu importieren (in einem anderen Prozess natürlich), sucht es erneut entlang seines sys.path nach der foo.py-Datei. Wenn Python die foo.py-Datei findet, sucht es nach einer übereinstimmenden __pycache__/foo.<magic>.pyc und liest diese, liest den Bytecode und fährt wie gewohnt fort.

Fall 3: __pycache__/foo.<magic>.pyc ohne Quellcode

Es ist möglich, dass die foo.py-Datei irgendwie entfernt wurde, während die zwischengespeicherte pyc-Datei noch auf dem Dateisystem verblieben ist. Wenn die __pycache__/foo.<magic>.pyc-Datei existiert, aber die foo.py-Datei, die zu ihrer Erstellung verwendet wurde, nicht mehr vorhanden ist, löst Python beim Versuch, foo zu importieren, einen ImportError aus. Mit anderen Worten: Python importiert keine pyc-Datei aus dem Cache-Verzeichnis, es sei denn, die Quelldatei existiert.

Fall 4: Legacy-pyc-Dateien und Imports ohne Quellcode

Python ignoriert alle Legacy-pyc-Dateien, wenn eine Quelldatei daneben existiert. Das heißt, wenn eine foo.pyc-Datei neben der foo.py-Datei existiert, wird die pyc-Datei in allen Fällen ignoriert.

Um jedoch weiterhin Distributions ohne Quellcode zu unterstützen, importiert Python eine einzelne pyc-Datei, wenn die Quelldatei fehlt und sich die pyc-Datei dort befindet, wo sich die Quelldatei befinden würde.

Fall 5: schreibgeschützte Dateisysteme

Wenn sich die Quelle auf einem schreibgeschützten Dateisystem befindet oder das __pycache__-Verzeichnis oder die pyc-Datei anderweitig nicht geschrieben werden kann, gelten alle Regeln. Dies ist auch der Fall, wenn __pycache__ zufällig mit Berechtigungen geschrieben wird, die das Schreiben von enthaltenden pyc-Dateien nicht zulassen.

Verfügbarkeit von PEP 3147 erkennen

Der einfachste Weg, um festzustellen, ob Ihre Python-Version PEP 3147-Funktionalität bietet, ist die folgende Prüfung:

>>> import imp
>>> has3147 = hasattr(imp, 'get_tag')

__file__

In Python 3 zeigt das Attribut __file__ eines Moduls, wenn es importiert wird, auf seine Quell-py-Datei (in Python 2 zeigt es auf die pyc-Datei). Das __file__ eines Pakets zeigt auf die py-Datei für sein __init__.py. Z. B.:

>>> import foo
>>> foo.__file__
'foo.py'
# baz is a package
>>> import baz
>>> baz.__file__
'baz/__init__.py'

Nichts in diesem PEP würde die Semantik von __file__ ändern.

Dieser PEP schlägt die Hinzufügung eines Attributs __cached__ zu Modulen vor, das immer auf die tatsächliche pyc-Datei verweist, die gelesen oder geschrieben wurde. Wenn die Umgebungsvariable $PYTHONDONTWRITEBYTECODE gesetzt ist, die Option -B gegeben wird oder wenn die Quelle auf einem schreibgeschützten Dateisystem liegt, dann verweist das Attribut __cached__ auf den Ort, an dem die pyc-Datei geschrieben worden *wäre*, wenn sie nicht existiert hätte. Dieser Ort schließt natürlich das __pycache__-Unterverzeichnis in seinem Pfad ein.

Für alternative Python-Implementierungen, die keine pyc-Dateien unterstützen, kann das Attribut __cached__ auf Informationen verweisen, die sinnvoll sind. Z. B. unter Jython könnte dies die .class-Datei für das Modul sein: __pycache__/foo.jython-32.class. Einige Implementierungen verwenden möglicherweise mehrere kompilierte Dateien, um das Modul zu erstellen. In diesem Fall kann __cached__ ein Tupel sein. Der genaue Inhalt von __cached__ ist Python-implementierungsspezifisch.

Es wird empfohlen, dass Implementierungen das Attribut __cached__ auf None setzen, wenn nichts Sinnvolles berechnet werden kann.

py_compile und compileall

Python wird mit zwei Modulen geliefert, py_compile [15] und compileall [16], die das Kompilieren von Python-Modulen außerhalb der integrierten Import-Maschinerie unterstützen. py_compile hat insbesondere intimes Wissen über die Byte-Kompilierung, daher werden diese aktualisiert, um das neue Layout zu verstehen. Das Flag -b wird zu compileall hinzugefügt, um Legacy .pyc-Byte-kompilierte Dateinamen zu schreiben.

bdist_wininst und der Windows-Installer

Diese Werkzeuge kompilieren Module auch explizit bei der Installation. Wenn sie nicht py_compile und compileall verwenden, müssten sie ebenfalls modifiziert werden, um das neue Layout zu verstehen.

Prüfung von Dateierweiterungen

Es gibt einige Codes, die nach Dateien suchen, die auf .pyc enden, und einfach das letzte Zeichen abschneiden, um die übereinstimmende .py-Datei zu finden. Dieser Code wird offensichtlich fehlschlagen, sobald dieser PEP implementiert ist.

Um diesen Anwendungsfall zu unterstützen, fügen wir zwei neue Methoden zum imp-Paket hinzu [17]:

• imp.cache_from_source(py_path) -> pyc_path
• imp.source_from_cache(pyc_path) -> py_path

Alternative Implementierungen sind frei, diese Funktionen zu überschreiben, um sinnvolle Werte basierend auf ihrer eigenen Unterstützung für diesen PEP zurückzugeben. Diese Methoden dürfen None zurückgeben, wenn die Implementierung (oder der aktive PEP 302-Loader) aus irgendeinem Grund den entsprechenden Dateinamen nicht berechnen kann. Sie sollten keine Ausnahmen auslösen.

Backports

Für Python-Versionen vor 3.2 (und möglicherweise 2.7) ist es möglich, diesen PEP als Backport zu integrieren. In Python 3.2 (und möglicherweise 2.7) wird dieses Verhalten jedoch standardmäßig aktiviert sein und das alte Verhalten ersetzen. Backports müssen das alte Layout standardmäßig unterstützen. Wir schlagen vor, PEP 3147 durch die Verwendung einer Umgebungsvariable namens $PYTHONENABLECACHEDIR oder des Befehlszeilenschalters -Xenablecachedir zu unterstützen, um die Funktion zu aktivieren.

Makefiles und andere Abhängigkeitstools

Makefiles und andere Tools, die Abhängigkeiten von .pyc-Dateien berechnen (z. B. um die Quelle byte-zu-kompilieren, wenn die .pyc fehlt), müssen aktualisiert werden, um die neuen Pfade zu überprüfen.

Hexadezimale Magic-Tags

pyc-Dateien innerhalb der __pycache__-Verzeichnisse enthalten einen magischen Tag in ihren Dateinamen. Dies sind mnemonische Tags für die tatsächlichen Magiczahlen, die vom Importer verwendet werden. Wir hätten die hexadezimale Darstellung [10] der binären Magiczahl als eindeutigen Identifikator verwenden können. Zum Beispiel in Python 3.2:

>>> from binascii import hexlify
>>> from imp import get_magic
>>> 'foo.{}.pyc'.format(hexlify(get_magic()).decode('ascii'))
'foo.580c0d0a.pyc'

Das ist jedoch nicht besonders menschenfreundlich, daher der im PEP vorgeschlagene magische Tag.

PEP 304

Es gibt einige Überschneidungen zwischen den Zielen dieses PEP und PEP 304, der zurückgezogen wurde. PEP 304 würde es einem Benutzer jedoch ermöglichen, eine Schatten-Dateisystemhierarchie zu erstellen, in der pyc-Dateien gespeichert werden. Dieses Konzept einer Schattenhierarchie für pyc-Dateien könnte verwendet werden, um die Ziele dieses PEP zu erfüllen. Obwohl PEP 304 nicht angibt, warum er zurückgezogen wurde, haben Schattenverzeichnisse eine Reihe von Problemen. Der Speicherort der Schatten-pyc-Dateien wäre nicht leicht zu finden und würde von der korrekten und konsistenten Verwendung der Umgebungsvariable $PYTHONBYTECODE sowohl durch das System als auch durch Endbenutzer abhängen. Es gibt auch globale Auswirkungen, was bedeutet, dass das System zwar pyc-Dateien schattieren möchte, Benutzer dies aber möglicherweise nicht tun möchten, aber der PEP nur einen Alles-oder-Nichts-Ansatz definiert.

Als Beispiel für das Problem wird ein gängiges (wenn auch fragiles) Python-Idiom zum Auffinden von Datendateien verwendet, indem etwas wie folgt gemacht wird:

from os import dirname, join
import foo.bar
data_file = join(dirname(foo.bar.__file__), 'my.dat')

Dies wäre problematisch, da foo.bar.__file__ den Speicherort der pyc-Datei im Schattenverzeichnis liefert und es von dort aus möglicherweise nicht möglich ist, die my.dat-Datei relativ zum Quellverzeichnis zu finden.

Fat Byte-Kompilierungsdateien

Eine frühere Version dieses PEP beschrieb „fat“ Python-Bytecode-Dateien. Diese Dateien würden das Äquivalent mehrerer pyc-Dateien in einer einzigen pyf-Datei enthalten, mit einer Lookup-Tabelle, die auf der entsprechenden Magiczahl basiert. Dies war ein erweiterbares Dateiformat, sodass die ersten 5 parallelen Python-Implementierungen ziemlich effizient unterstützt werden konnten, aber mit Lookup-Tabellen zur Erweiterung, um pyf-Bytecode-Objekte so groß wie nötig zu skalieren.

Die fat Byte-Kompilierungsdateien waren ziemlich komplex und führten inhärent zu schwierigen Race Conditions, daher wurde die aktuelle Vereinfachung der Verwendung von Verzeichnissen vorgeschlagen. Das gleiche Problem tritt bei der Verwendung von Zip-Dateien als fat pyc-Dateiformat auf.

Mehrere Dateierweiterungen

Der PEP-Autor berücksichtigte auch einen Ansatz, bei dem mehrere dünne Byte-kompilierte Dateien am selben Ort lebten, aber unterschiedliche Dateierweiterungen zur Bezeichnung der Python-Version verwendeten. Z. B. foo.pyc25, foo.pyc26, foo.pyc31 usw. Dies wurde aufgrund der Unübersichtlichkeit, die mit dem Schreiben so vieler verschiedener Dateien verbunden ist, abgelehnt. Der Ansatz mit mehreren Erweiterungen macht es schwieriger (und zu einer fortlaufenden Aufgabe), alle Tools zu aktualisieren, die von der Dateierweiterung abhängen.

.pyc

Es wurde ein Vorschlag gemacht, das __pycache__-Verzeichnis .pyc oder einen anderen Dot-File-Namen zu nennen. Dies hätte auf *nix-Systemen den Effekt, dass das Verzeichnis versteckt wird. Es gibt viele Gründe, warum dies vom BDFL [20] abgelehnt wurde, einschließlich der Tatsache, dass Dot-Files nur auf einigen Plattformen speziell sind, und wir diese Benutzer tatsächlich *nicht* komplett verstecken wollen.