Unterabschnitte


6. Module

Wenn Sie den Python-Interpreter verlassen und wieder starten, sind alle Definitionen, die Sie vorher eingegeben haben, verloren. Wenn Sie daher längere Programme schreiben wollen, ist es besser, einen Text-Editor zu benutzen, um die Eingabe für den Interpreter in eine Datei zu schreiben, die Sie mit dem Interpreter aufrufen. Das versteht man unter der Erzeugung eines Skriptes. Mit zunehmender Länge Ihres Programmes möchten Sie es vielleicht in mehrere Dateien aufteilen, um den Code besser warten zu können. Sie werden sicher auch praktische Funktionen benutzen wollen, die Sie in verschiedenen Programmen geschrieben haben, ohne die Definition in jedes einzelne Programm zu kopieren.

Um dies zu unterstützen, bietet Python die Möglichkeit, Definitionen in einer Datei abzulegen, um diese in einem Skript oder einer interaktiven Sitzung mit dem Interpreter zu benutzen. Eine solche Datei wird ein Modul genannt. Die Definitionen eines Moduls können in anderen Modulen oder im Hauptmodul, d.h. der Sammlung von Variablen und Definitionen, zu denen man von der obersten Aufrufebene Zugang hat, importiert werden.

Ein Modul ist eine Datei mit Python-Definitionen und -Anweisungen. Der Dateiname ist der Modulname mit dem Zusatz .py. Innerhalb eines Moduls ist der Modulname (als String) als Wert der globalen Variablen __name__ verfügbar. Benutzen Sie z.B. Ihren Lieblings-Text-Editor, um eine Datei fibo.py im aktuellen Verzeichnis mit folgendem Inhalt zu erzeugen:


# Fibonacci numbers module

def fib(n):    # Gib Fibonacci-Reihe bis n aus.
    a, b = 0, 1
    while b < n:
        print b,
        a, b = b, a+b

def fib2(n): # Gib Fibonacci-Reihe bis n aus.
    result = []
    a, b = 0, 1
    while b < n:
        result.append(b)
        a, b = b, a+b
    return result

Starten sie den Python-Interpreter und importieren Sie nun diesen Modul mit folgendem Kommando:


>>> import fibo

Das trägt nicht die Namen der in fibo definierten Funktionen in die Symboltabelle ein, sondern nur den Modulnamen fibo. Mit diesem Modulnamen hat man Zugriff auf die Funktionen:


>>> fibo.fib(1000)
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987
>>> fibo.fib2(100)
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> fibo.__name__
'fibo'
Wenn Sie vorhaben, eine Funktion oft zu benutzen, können Sie sie einem lokalen Namen zuweisen:


>>> fib = fibo.fib
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377


6.1 Mehr über Module

Ein Modul kann ausführbare Anweisungen wie auch Funktionsdefinitionen enthalten. Diese Anweisungen dienen der Initialisierung des Moduls. Sie werden nur dann ausgeführt, wenn das Modul das erste mal importiert wird.6.1

Jedes Modul hat seine eigene Symboltabelle, die von allen im Modul definierten Funktionen als globale Symboltabelle verwendet wird. Daher kann die Autorin eines Moduls globale Variablen innerhalb eines Moduls verwenden, ohne Angst vor versehentlichen, späteren Namenskonflikten mit den globalen Variablen der Benutzerin haben zu müssen. Auf der anderen Seite - wenn man weiß, was man macht - kann man die globalen Variablen eines Moduls mit der gleichen Notation wie für Funktionen manipulieren, modname.itemname.

Module können andere Module importieren. Es ist üblich, wenn auch nicht notwendig, alle import-Anweisungen zu Beginn eines Moduls (d.h. Skriptes) zu setzen. Die importierten Modulnamen werden in die globale Symboltabelle des importierenden Moduls eingetragen.

Es gibt eine Variante der import-Anweisung, die Namen aus einem Modulverzeichnis in die Symboltabelle des importierenden Moduls einträgt. Beispiel:


>>> from fibo import fib, fib2
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377

Das trägt nicht den Namen des Moduls, von dem die Symbole übernommen werden, in die lokale Symboltabelle ein, d.h. fibo in obigem Beispiel ist nicht definiert.

Es gibt sogar eine Variante, alle Namen zu importieren, die ein Modul definiert:


>>> from fibo import *
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377

Damit werden alle Namen mit Ausnahme derer, die mit einem Unterstrich beginnen (_), importiert.


6.1.1 Der Modul-Suchpfad

Wenn ein Modul namens spam importiert wird, sucht der Interpreter nach einer Datei mit Namen spam.py im aktuellen Verzeichnis und anschließend in der Liste der Verzeichnisse, die durch die Umgebungsvariable $PYTHONPATH spezifiziert wird. Diese hat die gleiche Syntax wie die Shell-Variable $PATH, d.h. eine Liste von Verzeichnisnamen. Wenn $PYTHONPATH nicht gesetzt ist oder wenn die Datei dort nicht gefunden wird, wird die Suche in einem von der Installation abhängigen Standardpfad fortgesetzt, unter Unix normalerweise /usr/local/lib/python.

Tatsächlich werden Module in einer Liste von Verzeichnissen gesucht, die durch die Variable sys.path bestimmt wird, die vom Verzeichnis mit dem Eingabe-Skript initialisiert wird (oder dem aktuellen Verzeichnis), $PYTHONPATH und der von der Installation abhängigen Standard-Einstellung. Das erlaubt es Python-Programmen, den Modul-Suchpfad zu modifizieren oder zu ersetzen. Siehe dazu auch den späteren Absatz über Standard-Module.

6.1.2 ,,Übersetzte`` Python-Dateien

Zur Beschleunigung der Startzeit für kurze Programme, die eine Menge Standard-Module verwenden, wird angenommen, daß eine Datei mit Namen spam.pyc in einem Verzeichnis, in dem spam.py gefunden wird, eine zuvor ,,Byte-übersetzte`` Version des Moduls spam darstellt. Der Zeitpunkt der letzten Änderung von spam.py, das zur Erzeugung von spam.pyc verwendet wurde, wird in spam.pyc festgehalten und die Datei wird ignoriert, falls diese zwei Punkte nicht übereinstimmen.

Normalerweise muß man nichts tun, um die Datei spam.pyc zu erzeugen. Immer wenn spam.py erfolgreich übersetzt wurde, wird der Versuch unternommen, die übersetzte Version nach spam.pyc zu schreiben. Falls dieser Versuch schiefgeht, so ist das kein Fehler. Wird aus irgendeinem Grund diese Datei nicht vollständig geschrieben, so wird die resultierende Datei spam.pyc als unvollständig erkannt und später ignoriert. Der Inhalt der Datei spam.pyc ist Plattform-unabhängig, so daß ein Python-Modulverzeichnis über Maschinen mit verschiedenen Architekturen hinweg verwendet werden kann.

Einige Tips für die Experten:


6.2 Standard-Module

Python wird mit einer Bibliothek von Standard-Modulen verbreitet, die in einem separaten Dokument, der Python Bibliotheks-Referenz (fortan nur noch ,,Bibliotheks-Referenz`` genannt) beschrieben wird. Einige Module sind in den Interpreter eingebaut und ermöglichen den Zugang zu Operationen, die nicht zum Kern der Sprache gehören, aber dennoch eingebaut sind, entweder aus Effizienzgründen oder um Zugang zu Betriebssystem-Primitiven, wie Systemaufrufen zu ermöglichen. Die Auswahl dieser Module ist abhängig von der jeweiligen Konfiguration. So wird das amoeba-Modul nur auf Systemen bereitgestellt, die irgendwie Amoeba-Primitive unterstützen. Ein Modul verdient besondere Beachtung: sys, das in jedem Python-Interpreter eingebaut ist. Die Variablen sys.ps1 und sys.ps2 definieren die Strings, die als primäre und sekundäre Prompts verwendet werden:


>>> import sys
>>> sys.ps1
'>>> '
>>> sys.ps2
'... '
>>> sys.ps1 = 'C> '
C> print 'Yuck!'
Yuck!
C>

Diese zwei Variablen sind nur definiert, wenn der Interpreter im interaktiven Modus ist.

Die Variable sys.path ist eine Liste von Strings, die den Modul-Suchpfad des Interpreters bestimmt. Sie wird mit dem Standardpfad initialisiert, der der Umgebungsvariablen $PYTHONPATH entnommen wird, oder von einem eingebauten Standard-Wert, falls $PYTHONPATH nicht gesetzt ist. Man kann sie mit den normalen Listen-Operationen modifizieren, z.B.:


>>> import sys
>>> sys.path.append('/ufs/guido/lib/python')


6.3 Die dir()-Funktion

Die eingebaute Funktion dir() wird verwendet, um herauszufinden, welche Namen in einem Modul definiert sind. Sie gibt eine sortierte Liste von Strings zurück:


>>> import fibo, sys
>>> dir(fibo)
['__name__', 'fib', 'fib2']
>>> dir(sys)
['__name__', 'argv', 'builtin_module_names', 'copyright', 'exit',
'maxint', 'modules', 'path', 'ps1', 'ps2', 'setprofile', 'settrace',
'stderr', 'stdin', 'stdout', 'version']

Ohne Argumente listet dir() all die Namen auf, die bisher definiert worden sind:


>>> a = [1, 2, 3, 4, 5]
>>> import fibo, sys
>>> fib = fibo.fib
>>> dir()
['__name__', 'a', 'fib', 'fibo', 'sys']

Man beachte, daß alle Arten von Namen aufgezählt werden: Variablen, Module, Funktionen, etc.

dir() führt die Namen von eingebauten Funktionen und Variablen nicht auf. Wenn Sie dennoch eine Liste davon benötigen: sie werden im Standard-Modul __builtin__ definiert:


>>> import __builtin__
>>> dir(__builtin__)
['AccessError', 'AttributeError', 'ConflictError', 'EOFError', 'IOError',
'ImportError', 'IndexError', 'KeyError', 'KeyboardInterrupt',
'MemoryError', 'NameError', 'None', 'OverflowError', 'RuntimeError',
'SyntaxError', 'SystemError', 'SystemExit', 'TypeError', 'ValueError',
'ZeroDivisionError', '__name__', 'abs', 'apply', 'chr', 'cmp', 'coerce',
'compile', 'dir', 'divmod', 'eval', 'execfile', 'filter', 'float',
'getattr', 'hasattr', 'hash', 'hex', 'id', 'input', 'int', 'len', 'long',
'map', 'max', 'min', 'oct', 'open', 'ord', 'pow', 'range', 'raw_input',
'reduce', 'reload', 'repr', 'round', 'setattr', 'str', 'type', 'xrange']


6.4 Pakete

Pakete bieten die Möglichkeit, den Namensraum von Python zu strukturieren, indem ,,qualifizierte Modulnamen`` verwendet werden. Zum Beispiel beschreibt der Modulname A.B ein Untermodul namens "B" im Paket "A". Genauso wie die Verwendung von Modulen die Autoren verschiedener Module davor bewahrt, sich Sorgen um ihre globalen Variablen zu machen, bewahrt die Verwendung von qualifizierten Modulnamen die Autoren von Paketen mit mehreren Modulen wie NumPy oder PIL davor, sich Sorgen um die Verwendung der eigenen Modulnamen durch andere Autoren zu machen.

Angenommen, Sie wollen eine Sammlung von Modulen (ein ,,Paket``) für die einheitliche Handhabung von Audio-Dateien und -Daten entwerfen. Es gibt viele verschiedene Audio-Dateiformate (normalerweise an ihrer Erweiterung zu erkennen, z.B. .wav, .aiff, .au), so daß Sie vermutlich eine wachsende Anzahl von Modulen für die Umwandlung zwischen diesen verschiedenen Formaten erstellen und warten müssen. Ebenso gibt es viele verschiedene Operationen, die Sie vielleicht auf Audio-Daten vornehmen möchten (z.B. Mixen, Echo hinzufügen, eine Equalizer-Funktion anwenden, einen künstlichen Stereo-Effekt erzeugen), so daß Sie zusätzlich eine nicht enden wollende Kette von Modulen schreiben müssen, um auch diese Operationen zu implementieren. Dies wäre eine mögliche Struktur Ihres Pakets (ausgedrückt als hierarchisches Dateisystem):


Sound/                          Top-level package
      __init__.py               Initialize the sound package
      Formats/                  Subpackage for file format conversions
              __init__.py
              wavread.py
              wavwrite.py
              aiffread.py
              aiffwrite.py
              auread.py
              auwrite.py
              ...
      Effects/                  Subpackage for sound effects
              __init__.py
              echo.py
              surround.py
              reverse.py
              ...
      Filters/                  Subpackage for filters
              __init__.py
              equalizer.py
              vocoder.py
              karaoke.py
              ...

Die __init__.py-Dateien werden benötigt, um Python die Verzeichnisse als Pakete behandeln zu lassen, was verhindert, daß Verzeichnisse mit gängigen Namen wie z.B. "string" unabsichtlich spätere Module im Suchpfad verdecken. Im einfachsten Fall kann __init__.py einfach eine leere Datei sein, aber sie kann auch Initialisierungscode für das Paket enthalten oder die Variable __all__ setzen, die später beschrieben wird.

Benutzerinnen des Paketes können einzelne Module daraus importieren, z.B.:


import Sound.Effects.echo
Das lädt das Untermodul Sound.Effects.echo. Es muß mit seinem vollständigen Namen referenziert werden, z.B.:


Sound.Effects.echo.echofilter(input, output, delay=0.7, atten=4)
Eine alternative Art, ein Untermodul zu importieren, ist:


from Sound.Effects import echo
Das lädt auch das Untermodul echo und macht es ohne sein Paket-Präfix verfügbar:


echo.echofilter(input, output, delay=0.7, atten=4)

Wieder eine andere Variante ist, die gewünschte Funktion oder Variable direkt zu importieren:


from Sound.Effects.echo import echofilter

Wieder lädt dies das Untermodul echo, aber dessen Funktion echofilter wird direkt verfügbar gemacht:


echofilter(input, output, delay=0.7, atten=4)

Man beachte, daß bei Verwendung von from package import item, das zu ladende Element entweder ein Untermodul (oder Unterpaket) des Paketes sein kann oder ein anderer darin definierter Name, etwa eine Funktion, Klasse oder Variable. Die import-Anweisung prüft zuerst, ob das Element im Paket definiert ist. Wenn nicht, nimmt sie an, es handelt sich um ein Modul und versucht, es zu laden. Wenn dieser Versuch schiefgeht, wird ein ImportError ausgelöst.

Umgekehrt muß bei Verwendung der import item.subitem.subsubitem-Syntax jedes Element, bis auf das letzte ein Paket sein. Das letzte kann ein Modul oder ein Paket sein, aber keine Klasse oder Funktion, die im vorherigen Element definiert wäre.


6.4.1 Importieren von * aus einem Paket

Was passiert nun, wenn die Benutzerin from Sound.Effects import * schreibt? Idealerweise würde man hoffen, daß dies nun im Dateisystem sucht und erkennt, welche Untermodule im Paket da sind und sie alle importiert. Dummerweise funktioniert diese Operation auf der Mac- und Windows-Plattform nicht so gut, da das Dateisystem oft nicht über exakte Angaben der Schreibweise eines Dateinamens verfügt! Auf diesen Plattformen gibt es keine Garantie, zu wissen, ob ECHO.PY als Modul echo, Echo oder ECHO importiert werden soll. (Zum Beispiel hat Windows 95 die ärgerliche Eigenschaft, alle Dateinamen mit einem großen Anfangsbuchstaben anzuzeigen.) Die Einschränkung von Dateinamen auf 8+3 Buchstaben unter DOS bringt weitere interessante Probleme für lange Modulnamen mit sich.

Die einzige Lösung für die Autorin eines Paketes ist es, einen expliziten Index des Paketes anzugeben. Die import-Anweisung verwendet dabei folgende Konvention: falls die Datei __init__.py eines Paketes eine Liste namens __all__ definiert, wird sie als Liste von Modulnamen aufgefaßt, die importiert werden sollen, wenn Code der Art from package import * gefunden wird. Es liegt an der Autorin des Paketes, diese Liste auf dem neuesten Stand zu halten, wenn eine neue Version des Paketes veröffentlicht wird. Autorinnen können diese Eigenschaft auch bewußt nicht unterstützen, wenn sie keinen Nutzen darin sehen, * aus ihrem Paket zu importieren. Die Datei Sounds/Effects/__init__.py könnte z.B. den folgenden Code enthalten:


__all__ = ["echo", "surround", "reverse"]

Das würde bedeuten, daß from Sound.Effects import * die angegebenen drei Untermodule vom Sound-Paket importieren würde.

Falls __all__ nicht definiert ist, importiert die Anweisung from Sound.Effects import * nicht alle Untermodule des Sound.Effects-Paketes in den aktuellen Namensraum, sondern stellt nur sicher, daß das Paket Sound.Effects importiert wird (möglicherweise, indem sein Initialisierungscode, __init__.py, ausgeführt wird) und importiert dann, welche Namen auch immer im Paket definiert sind. Das beinhaltet alle in __init__.py definierten Namen (und explizit geladenen Untermodule) und ebenso alle Untermodule des Pakets, die von vorherigen import-Anweisungen explizit geladen wurden, z.B.


import Sound.Effects.echo
import Sound.Effects.surround
from Sound.Effects import *

In diesem Beispiel werden die Module echo und surround in den aktuellen Namensraum importiert, da sie im Paket Sound.Effects definiert sind, wenn die from...import-Anweisung ausgeführt wird. (Das funktioniert auch, wenn __all__ definiert ist.)

Man beachte, daß im Allgemeinen davon abgeraten wird, * aus einem Modul oder Paket zu importieren, da es häufig zu schlecht lesbarem Code führt. Es ist jedoch in Ordnung, wenn man es in einer interaktiven Sitzung benutzt, um Tipp-Arbeit zu sparen. Außerdem sind gewisse Module so entworfen, daß sie Namen nach einem bestimmten Muster exportieren.

Es ist aber nichts falsch daran, from Package import specific_submodule zu verwenden! Tatsächlich ist dies die empfohlene Notation, solange das importierende Modul keine Untermodule mit dem gleichen Namen aus verschiedenen Paketen verwenden muß.

6.4.2 Referenzen innerhalb von Paketen

Untermodule müssen häufig aufeinander Bezug nehmen (sich referenzieren). Zum Beispiel könnte das Modul surround das echo-Modul benutzen. Tatsächlich kommen solche Referenzen so oft vor, daß die import-Anweisung zuerst ins umgebende Paket nachschaut, bevor der Modul-Suchpfad inspiziert wird. Daher kann das umgebende Modul einfach import echo oder from echo import echofilter benutzen. Falls das importierte Modul im aktuellen Paket nicht gefunden wird (das Paket, dessen aktuelles Modul ein Untermodul ist), schaut die import-Anweisung auf oberster Ebene nach einem Modul mit dem angegebenen Namen.

Wenn Pakete in Unterpakete organisiert werden (wie mit dem Sound-Paket im Beispiel), gibt es keine Abkürzung, um Untermodule von Schwester-Paketen zu referenzieren, sondern es muß der vollständige Name des Paketes verwendet werden. Falls z.B. das Modul Sound.Filters.vocoder das echo-Modul im Sound.Effects-Paket benutzen muß, kann es from Sound.Effects import echo verwenden.



Fußnoten

... wird.6.1
Tatsächlich sind Funktionsdefinitionen auch ,,Anweisungen`` die ,,ausgeführt`` werden; die Ausführung bewirkt, daß der Funktionsname in die Symboltabelle eingetragen wird.


Send comments to python-docs@python.org.