Ist __init__.py nicht für Pakete in Python 3.3 erforderlich?
Python 3.3 und spätere Versionen führen das Konzept von Namespace-Pakete. Mit dieser Funktion können Sie ein Paket ohne eine __init__.py-Datei erstellen.
Namespace-Pakete im Vergleich zu regulären Paketen
- Namespace-Pakete: Verfügen Sie nicht über eine __init__.py-Datei, sodass mehrere Module über verschiedene Module hinweg zum selben Paket beitragen können Verzeichnisse.
- Reguläre Pakete: Verfügen über eine __init__.py-Datei, wodurch sie eigenständig sind und ihre Module in einer einzigen Verzeichnishierarchie isoliert werden.
< h2>Wann Namespace-Pakete verwendet werden sollten
Der primäre Anwendungsfall für Namespace Bei Paketen handelt es sich, wenn Sie über mehrere Bibliotheken an verschiedenen Standorten verfügen und möchten, dass diese ein Unterpaket zum übergeordneten Paket beitragen.
Zum Beispiel:
google_pubsub/ <- Paket 1
google/ <- Namespace package (no __init__.py)
cloud/ <- Namespace package (no __init__.py)
pubsub/ <- Regular package (with __init__.py)
__init__.py <- Required to make the package a regular package
foo.py
Nach dem Login kopieren
google_storage/ <- Paket 2
google/ <- Namespace package (no __init__.py)
cloud/ <- Namespace package (no __init__.py)
storage/ <- Regular package (with __init__.py)
__init__.py <- Required to make the package a regular package
bar.py
Nach dem Login kopieren
In diesem Beispiel teilen sich google_pubsub und google_storage denselben Google/Cloud-Namespace. Dadurch können Sie Module aus beiden Bibliotheken importieren, ohne den vollständigen Pfad anzugeben.
Reguläre Pakete
Für die meisten Anwendungsfälle ist das Erstellen regulärer Pakete mit __init__.py-Dateien erforderlich ist immer noch der empfohlene Ansatz. Dies sorgt für Eigenständigkeit und verhindert potenzielle Namespace-Konflikte.
Das obige ist der detaillierte Inhalt vonBeseitigt Python 3.3 die Notwendigkeit von __init__.py in Paketen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!