6. Module¶
Wenn man den Python-Interpreter beendet und erneut startet, gehen alle vorgenommenen Definitionen (Funktionen und Variablen) verloren. Deshalb benutzt man vorzugsweise einen Text-Editor, um längere und komplexere Programme zu schreiben und verwendet eine Datei als Eingabe für den Interpreter. Diese Datei wird auch als Skript bezeichnet. Wird ein Programm länger, teilt man es besser in mehrere Dateien auf, um es leichter warten zu können. Außerdem ist es von Vorteil, nützliche Funktionen in mehreren Programmen verwenden zu können, ohne sie in jedem Programm erneut definieren zu müssen.
Hierfür bietet Python die Möglichkeit, etwas in einer Datei zu definieren und diese in einer anderen Datei oder in der interaktiven Konsole wieder zu verwenden. So eine Datei wird als Modul bezeichnet. Definitionen eines Moduls können in anderen Modulen oder in das Hauptmodul importiert werden, welches die Gesamtheit aller Funktionen und Variablen enthält, auf die man in einem Skript zugreifen kann.
Ein Modul ist eine Datei, die Python-Definitionen und -Anweisungen beinhaltet.
Der Dateiname mit dem .py
-Suffix entspricht dem Namen des Moduls.
Innerhalb eines Moduls ist der Modulname als __name__
verfügbar (globale
Variable des Typs String). Zum Beispiel: Öffne einen Editor Deiner Wahl und
erstelle eine Datei im aktuellen Verzeichnis mit dem Namen fibo.py
und
folgendem Inhalt:
# Fibonacci-Zahlen-Modul
def fib(n): # schreibe Fibonacci-Folge bis n
a, b = 0, 1
while b < n:
print(b, end=' ')
a, b = b, a+b
print()
def fib2(n): # gib die Fibonacci-Folge zurück bis n
result = []
a, b = 0, 1
while b < n:
result.append(b)
a, b = b, a+b
return result
Öffne danach Deinen Python-Interpreter und importiere das Modul mit folgendem Befehl:
>>> import fibo
Dieser Befehl fügt die von fibo.py
definierten Funktionen nicht
automatisch in die globale Symboltabelle (symbol table) ein, sondern nur den
Modulnamen fibo
. Um die Funktionen anzusprechen, benutzt man den
Modulnamen:
>>> 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 man plant, eine Funktion öfters zu verwenden, kann man diese an einen lokalen Namen binden.
>>> fib = fibo.fib
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377
6.1. Mehr zum Thema Module¶
Ein Modul kann sowohl ausführbare Anweisungen, als auch Definitionen einer Funktion enthalten. Diese Anweisungen sind dazu gedacht, das Modul zu initialisieren, und werden nur ausgeführt, wenn das Modul zum ersten Mal importiert wird.
Jedes Modul hat seine eigene, private Symboltabelle, welche wiederum als globale
Symboltabelle von allen Funktion in diesem Modul verwendet wird. Daher kann der
Verfasser eines Moduls ohne Bedenken globale Variablen in seinem Modul
verwenden, da sie sich nicht mit den globalen Variablen des Benutzers
überschneiden können. Andererseits kann man (wenn man weiß, was man tut) auch
die globalen Variablen eines Moduls verändern, indem man die gleiche
Schreibweise verwendet, um auch dessen Funktionen anzusprechen,
modname.itemname
.
Module können andere Module importieren. Es ist üblich, aber nicht zwingend
notwendig, dass man alle import
-Anweisungen an den Anfang eines
Moduls setzt (oder in diesem Fall Skripts). Die Namen der importierten Module
werden in die Symboltabelle des importierenden Moduls eingefügt.
Es gibt eine Variante der import
-Anweisung, welche bestimmte Namen aus
einem Modul direkt in die Symboltabelle des importierenden Moduls einfügt.
Beispielsweise:
>>> from fibo import fib, fib2
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377
Diese Variante fügt allerdings nicht den Modulnamen, aus dem die Namen
importiert werden, in die lokale Symboltabelle ein, sondern nur die
aufgeführten. In diesem Beispiel wird fibo
also nicht eingefügt.
Zusätzlich gibt es eine Variante um alle Namen eines Moduls zu importieren:
>>> from fibo import *
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 37
Hiermit werden alle Namen, sofern sie nicht mit einem Unterstrich (_) beginnen , importiert. In den meisten Fällen wird diese Variante nicht verwendet, denn dadurch werden unbekannte Namen in den Interpreter importiert und so kann es vorkommen, dass einige Namen überschrieben werden, die bereits definiert worden sind.
Beachte, dass der *
-Import eines Moduls oder Paketes im allgemeinen verpönt
ist, da er oft schlecht lesbaren Code verursacht. Allerdings ist es in Ordnung
ihn im interaktiven Interpreter zu benutzen, um weniger tippen zu müssen.
Bemerkung
Aus Effizienzgründen wird jedes Modul nur einmal durch eine
Interpreter-Sitzung importiert. Deshalb muss man den Interpreter bei
Veränderung der Module neustarten - oder man benutzt imp.reload()
,
beispielsweise import imp; imp.reload(modulename)
, falls es nur ein
Modul ist, welches man interaktiv testen will.
6.1.1. Module als Skript aufrufen¶
Wenn man ein Python-Modul folgendermaßen aufruft:
python fibo.py <Argumente>
wird der Code im Modul genauso ausgeführt, als hätte man das Modul importiert.
Der einzige Unterschied ist, dass __name__
jetzt "__main__"
ist und
nicht mehr der Name des Moduls. Wenn man nun folgende Zeilen an das Ende des
Moduls anfügt:
if __name__ == "__main__":
import sys
fib(int(sys.argv[1]))
kann man die Datei sowohl als Skript als auch als importierbares Modul nutzen, da der Code, der die Kommandozeile auswertet, nur ausgeführt wird, wenn das Modul direkt als Hauptdatei ausgeführt wird:
$ python fibo.py 50
1 1 2 3 5 8 13 21 34
Beim Import des Moduls wird dieser Code nicht ausgeführt:
>>> import fibo
>>>
Dies wird oft dazu verwendet, um entweder eine bequeme Benutzerschnittstelle zum Modul bereitzustellen oder zu Testzwecken (wenn das Modul als Skript ausgeführt wird, wird eine Testsuite gestartet).
6.1.2. Der Modul-Suchpfad¶
Wenn ein Modul mit dem Namen spam
importiert wird, sucht der Interpreter
zuerst nach einem eingebauten Modul mit diesem Namen. Wird es nicht gefunden,
sucht er nach einer Datei, die spam.py
benannt ist, in der Liste von
Verzeichnissen der Variable sys.path
. sys.path
wird mit
- dem Verzeichnis, das das Eingabeskript enthält (oder das aktuelle Verzeichnis),
PYTHONPATH
(eine Liste von Verzeichnissen, mit derselben Syntax wie die Shell-VariablePATH
)- der installationsabhängige Standard.
Nach der Initialisierung können Python-Programme sys.path
modifizieren. Das Verzeichnis, das das laufende Skript enthält befindet sich am
Anfang des Suchpfads, noch vor den Pfaden der Standardbibliothek. Das bedeutet,
dass Module in diesem Verzeichnis anstelle von Modulen der Standardbibliothek
geladen werden, wenn sie denselben Namen haben. Dies ist ein Fehler, sofern man
das Modul der Standardbibliothek nicht ersetzen will. Siehe Abschnitt
Standardmodule für mehr Informationen.
6.1.3. “Kompilierte” Python-Dateien¶
Um den Start von kurzen Programmen, die viele Standardmodule verwenden,
schneller zu machen, werden Dateien erstellt, welche bereits “byte-kompiliert”
sind. Existiert eine Datei mit dem Namen spam.pyc
, so ist das eine
“byte-kompilierte” Version der Datei spam.py
und des Moduls spam
.
Der Zeitpunkt an dem die Datei spam.py
zuletzt geändert wurde, wird in
spam.pyc
festgehalten. Falls die Zeiten nicht übereinstimmen, wird die
.pyc
ignoriert.
Normalerweise muss man nichts tun, damit die spam.pyc
-Datei erstellt
wird. Immer, wenn spam.py
erfolgreich kompiliert wird, wird auch
versucht die kompilierte Version in spam.pyc
zu schreiben. Es wird kein
Fehler geworfen, wenn der Vorgang scheitert; wenn aus irgendeinem Grund die
Datei nicht vollständig geschrieben sein sollte, wird die daraus resultierende
spam.pyc
automatisch als fehlerhaft erkannt und damit später ignoriert.
Der Inhalt der spam.pyc
ist plattformunabhängig, wodurch man ein Modul
Verzeichnis mit anderen Maschinen ohne Rücksicht auf ihre Architektur teilen
kann.
Einige Tipps für Experten:
- Wird der Python-Interpreter mit dem
-O
-Flag gestartet, so wird der optimierte Code in.pyo
-Dateien gespeichert. Optimierter Code hilft momentan nicht viel, da er lediglichassert
-Anweisungen entfernt. Wird-O
verwendet, wird der komplette Bytecode optimiert;.pyc
werden ignoriert und.py
-Dateien werden zu optimiertem Bytecode kompiliert. - Werden dem Python-Interpreter zwei
-O
-Flags übergeben, vollzieht der Bytecode-Compiler Optimierungen, die zu einer Fehlfunktion des Programms führen können. Momentan werden nur__doc__
-Strings aus dem Bytecode entfernt, was zu kleineren.pyo
-Dateien führt. Da einige Programme sich darauf verlassen, dass sie verfügbar sind, sollte man diese Option nur aktivieren, wenn man weiß, was man tut. - Ein Programm wird in keinster Weise schneller ausgeführt, wenn es aus einer
.pyc
oder.pyo
anstatt aus einer.py
-Datei gelesen wird. Der einzige Geschwindigkeitsvorteil ist beim Starten der Dateien. - Wenn ein Skript durch das Aufrufen über die Kommandozeile ausgeführt wird,
wird der Bytecode nie in eine
.pyc
- oder.pyo
-Datei geschrieben. Deshalb kann die Startzeit eines Skripts durch das Auslagern des Codes in ein Modul reduziert werden. Es ist auch möglich eine.pyc
- oder.pyo
-Datei direkt in der Kommandozeile auszuführen. - Es ist möglich, eine
.pyc
- oder.pyo
-Datei zu haben, ohne dass eine Datei mit dem Namenspam.py
für selbiges Modul existiert. Dies kann dazu genutzt werden, Python-Code auszuliefern, der relativ schwer rekonstruiert werden kann. - Das Modul
compileall
kann.pyc
-Dateien (oder auch.pyo
, wenn-O
genutzt wird) aus allen Modulen eines Verzeichnisses erzeugen.
6.2. Standardmodule¶
Python wird mit einer Bibliothek von Standardmodulen ausgeliefert, welche in der
Python Library Reference beschrieben werden. Einige Module sind in den
Interpreter eingebaut. Diese bieten Zugang zu Operationen, die nicht Teil des
Sprachkerns sind, aber trotzdem eingebaut sind. Entweder, um Zugang zu
Systemoperationen (wie z. B. Systemaufrufe) bereitzustellen oder aus
Effizienzgründen. Die Zusammenstellung dieser Module ist eine Option in der
Konfiguration, welche auch von der verwendeten Plattform abhängig ist.
Beispielsweise ist das winreg
-Modul nur unter Windows-Systemen verfügbar.
Ein bestimmtes Modul verdient besondere Aufmerksamkeit: sys
, welches in
jeden Python-Interpreter eingebaut ist. Die Variablen sys.ps1
und
sys.ps2
definieren die primären und sekundären Eingabeaufforderungen, die in
der Kommandozeile verwendet werden:
>>> import sys
>>> sys.ps1
'>>> '
>>> sys.ps2
'... '
>>> sys.ps1 = 'C> '
C> print('Yuck!')
Yuck!
C>
Diese beiden Variablen werden nur definiert, wenn der Interpreter im interaktiven Modus ist.
Die Variable sys.path
ist eine Liste von Zeichenketten, die den Suchpfad des
Interpreters vorgibt. Sie ist mit einem Standardpfad voreingestellt, der aus der
Umgebungsvariable PYTHONPATH
entnommen wird oder aus einem eingebauten
Standardwert, falls PYTHONPATH
nicht gesetzt ist. Man kann diese
Variable mit normalen Listenoperationen verändern:
>>> import sys
>>> sys.path.append('/ufs/guido/lib/python')
6.3. Die dir()
-Funktion¶
Die eingebaute Funktion dir()
wird benutzt, um herauszufinden, welche
Namen in einem Modul definiert sind. Es wird eine sortierte Liste von Strings
zurückgegeben:
>>> import fibo, sys
>>> dir(fibo)
['__name__', 'fib', 'fib2']
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', '__name__', '__stderr__',
'__stdin__', '__stdout__', '_getframe', 'api_version', 'argv',
'builtin_module_names', 'byteorder', 'callstats', 'copyright',
'displayhook', 'exc_info', 'excepthook', 'exec_prefix', 'executable',
'exit', 'getdefaultencoding', 'getdlopenflags', 'getrecursionlimit',
'getrefcount', 'hexversion', 'maxint', 'maxunicode', 'meta_path', 'modules',
'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'ps1',
'ps2', 'setcheckinterval', 'setdlopenflags', 'setprofile',
'setrecursionlimit', 'settrace', 'stderr', 'stdin', 'stdout', 'version',
'version_info', 'warnoptions']
Wenn man keine Parameter übergibt, liefert dir()
eine Liste der aktuell
definierten Namen:
>>> a = [1, 2, 3, 4, 5]
>>> import fibo
>>> fib = fibo.fib
>>> dir()
['__builtins__', '__doc__', '__file__', '__name__', 'a', 'fib', 'fibo',
'sys']
Zu Beachten ist, dass alle Typen von Namen ausgegeben werden: Variablen, Module, Funktionen, etc.
dir()
listet allerdings nicht die Namen der eingebauten Funktionen und
Variablen auf. Falls man diese auflisten will, muss man das Standardmodul
builtins
verwenden:
>>> import builtins
>>> dir(builtins)
['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException',
'BufferError', 'BytesWarning', 'DeprecationWarning', 'EOFError', 'Ellipsis',
'EnvironmentError', 'Exception', 'False', 'FloatingPointError',
'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning',
'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt',
'LookupError', 'MemoryError', 'NameError', 'None', 'NotImplemented',
'NotImplementedError', 'OSError', 'OverflowError',
'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError',
'RuntimeWarning', 'StopIteration', 'SyntaxError', 'SyntaxWarning',
'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError',
'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError',
'UnicodeError', 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning',
'ValueError', 'Warning', 'ZeroDivisionError', '__build_class__',
'__debug__', '__doc__', '__import__', '__name__', '__package__', 'abs',
'all', 'any', 'ascii', 'bin', 'bool', 'bytearray', 'bytes', 'chr',
'classmethod', 'compile', 'complex', 'copyright', 'credits', 'delattr',
'dict', 'dir', 'divmod', 'enumerate', 'eval', 'exec', 'exit', 'filter',
'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash',
'help', 'hex', 'id', 'input', 'int', 'isinstance', 'issubclass', 'iter',
'len', 'license', 'list', 'locals', 'map', 'max', 'memoryview', 'min',
'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit',
'range', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted',
'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'vars', 'zip']
6.4. Pakete¶
Pakete werden dazu verwendet, den Modul-Namensraum von Python zu strukturieren,
indem man Modulnamen durch Punkte trennt. Zum Beispiel verweist A.B
auf
ein Untermodul B
im Paket A
. Genauso wie die Verwendung von Modulen den
Autor von Modulen davor bewahrt, sich Sorgen um andere globale Variablennamen zu
machen, so bewahrt die Verwendung von Modulen, die durch mehrere Punkte getrennt
sind, den Autor davor, sich Sorgen um andere Modulnamen machen zu müssen.
Angenommen man will eine Sammlung von Modulen (ein “Paket”) erstellen, um
Audiodateien und -daten einheitlich zu bearbeiten. Es gibt unzählige
verschiedene Audioformate (gewöhnlicherweise erkennt man diese an Ihrer
Dateiendung, z.B. .wav
, .aiff
, .au
), sodass man eine
ständig wachsende Sammlung von Modulen erstellen und warten muss. Außerdem will
man auch verschiedene Arbeiten an den Audiodaten verrichten (wie zum Beispiel
Mixen, Echo hinzufügen, etc.), also wird man immer wieder Module schreiben, die
diese Arbeiten ausführen. Hier eine mögliche Struktur für so ein Paket
(ausgedrückt in der Form eines hierarchischen Dateisystems):
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
...
Wenn man das Paket importiert, sucht Python durch die Verzeichnisse im
sys.path
, um nach dem Paket in einem Unterverzeichnis zu suchen.
Die __init__.py
-Datei wird benötigt, damit Python das Verzeichnis als
Paket behandelt. Dies hat den Grund, dass Verzeichnisse mit einem normalen
Namen, wie z.B. string
, nicht unbeabsichtigt Module verstecken, die weiter
hinten im Suchpfad erscheinen. Im einfachsten Fall ist __init__.py
eine
leere Datei, sie kann allerdings auch Initialisierungscode für das Paket
enthalten oder die __all__
-Variable setzen, welche später genauer
beschrieben wird.
Benutzer eines Pakets können individuelle Module aus dem Paket importieren:
import sound.effects.echo
Dieser Vorgang lädt das Untermodul sound.effects.echo
. Es muss mit seinem
kompletten Namen referenziert werden:
sound.effects.echo.echofilter(input, output, delay=0.7, atten=4)
Eine alternative Methode, um dieses Untermodul zu importieren:
from sound.effects import echo
Diese Variante lädt auch das Untermodul echo
, macht es aber ohne seinen
Paket-Präfix verfügbar. Man verwendet es folgendermaßen:
echo.echofilter(input, output, delay=0.7, atten=4)
Eine weitere Möglichkeit ist, die beschriebene Funktion oder Variable direkt zu importieren:
from sound.effects.echo import echofilter
Genau wie in den anderen Beispielen, lädt dies das Untermodul echo
. In
diesem Fall wird aber die echofilter()
Funktion direkt verfügbar gemacht:
echofilter(input, output, delay=0.7, atten=4)
Wenn man from package import item
verwendet, kann das item
entweder ein
Untermodul und -paket sein oder ein Name, der in diesem Paket definiert ist (z.
B. eine Funktion, eine Klasse oder Variable). Die import
-Anweisung überprüft
zuerst, ob das item
in diesem Paket definiert ist; falls nicht, wird von
einem Modul ausgegangen und versucht es zu laden. Wenn nichts gefunden wird,
wird eine ImportError
-Ausnahme geworfen.
Im Gegensatz dazu, muss bei Verwendung von import item.subitem.subsubitem
jedes item
ein Paket sein; das letzte item
kann ein Modul oder ein Paket
sein, aber es darf keine Klasse, Funktion oder Variable im darüber geordneten
item
sein.
6.4.1. * aus einem Paket importieren¶
Was passiert nun, wenn der Benutzer from sound.effects import *
schreibt?
Idealerweise würde man hoffen, dass dies irgendwie an das Dateisystem
weitergereicht wird und alle Untermodule, die es im Paket gibt, findet und sie
alle importiert. Das könnte sehr lange dauern und Untermodule zu importieren
könnte Nebeneffekte hervorrufen, die nur dann auftreten sollten, wenn das
Untermodul explizit importiert wird.
Die einzige Lösung ist, dass der Autor des Paketes einen expliziten Index des
Paketes bereitstellt. Die import
-Anweisung folgt folgender
Konvention: Definiert die Datei __init__.py
des Paketes eine Liste
namens __all__
, wird diese als Liste der Modulnamen behandelt, die bei
from package import *
importiert werden sollen. Es ist Aufgabe des
Paketautoren diese Liste aktuell zu halten, wenn er eine neue Version des
Paketes veröffentlicht. Paketautoren können sich auch entscheiden es nicht zu
unterstützen, wenn sie einen *-Import ihres Paketes für nutzlos halten. Zum
Beispiel könnte die Datei sound/effects/__init__.py
folgenden Code
enthalten:
__all__ = ["echo", "surround", "reverse"]
Dies würde bedeuten, dass from sound.effects import *
die drei genannten
Untermodule des sound
Paketes importiert.
Ist __all__
nicht definiert, importiert die Anweisung from sound.effects
import *
nicht alle Untermodule des Paketes sound.effects
in den
aktuellen Namensraum; es stellt nur sicher, dass das Paket sound.effects
importiert wurde (möglicherweise führt es jeglichen Initialisierungscode in
__init__.py
aus) und importiert dann alle Namen, die im Paket definiert
wurden. Inklusive der Namen, die in __init__.py
definiert werden (und
Untermodule die explizit geladen werden). Es bindet auch jegliche Untermodule
des Paketes ein, die durch vorherige import
-Anweisungen explizit
geladen wurden. Schau Dir mal diesen Code an:
import sound.effects.echo
import sound.effects.surround
from sound.effects import *
Hier werden die Module echo
und surround
in den aktuellen
Namensraum importiert, da sie im Paket sound.effects
definiert sind, wenn
die Anweisung from ... import
ausgeführt wird. (Das funktioniert auch wenn
__all__
definiert ist.)
Auch wenn manche Module so entworfen wurden, nur Namen, die einem bestimmten
Namensschema folgen, bei einem import *
zu exportieren, wird es dennoch als
schlechte Praxis betrachtet.
Aber bedenke, dass an der Benutzung von from Package import
specific_submodule
nichts falsch ist! In der Tat ist es die empfohlene
Schreibweise, es sei denn das importierende Modul benutzt gleichnamige
Untermodule von anderen Paketen.
6.4.2. Referenzen innerhalb des Paketes¶
Werden Pakete in Unterpakete strukturiert (wie das sound
-Paket im
Beispiel), kann man absolute Importe benutzen um Untermodule der
Geschwisterpakete zu referenzieren. Wenn das Modul sound.filters.vocoder
beispielsweise das Modul echo
im Paket sound.effects
benutzen
muss, kann es from sound.effects import echo
nutzen.
Man kann auch relative Importe in der from module import name
-Form der
import
-Anweisung nutzen. Diese Importe nutzen führende Punkte, um das
aktuelle und die Elternpakete, die im relativen Import beteiligt sind,
anzugeben. Aus dem surround
-Modul heraus, könnte man beispielsweise
folgendes nutzen:
from . import echo
from .. import formats
from ..filters import equalizer
Beachte, dass relative Importe auf dem Namen des aktuellen Moduls basieren. Da
der Name des Hauptmoduls immer "__main__"
ist, müssen Module, die als
Hauptmodul einer Python-Anwendung gedacht sind, immer absolute Importe nutzen.
6.4.3. Pakete in mehreren Verzeichnissen¶
Pakete unterstützen ein weiteres besonderes Attribut: __path__
. Es wird
als Liste initialisiert, die den Namen des Verzeichnisses mit der
__init__.py
des Pakets enthält. Dies geschieht, bevor der Code in dieser
Datei ausgeführt wird. Diese Variable kann verändert werden und eine Änderung
beeinflusst zukünftige Suchen nach Modulen und Unterpaketen, die im Paket
enthalten sind.
Auch wenn dieses Feature nicht oft gebraucht wird, kann sie benutzt werden um die Menge der Module, die in einem Paket gefunden werden, zu erweitern.
Fußnoten
[1] | Eigentlich sind Funktionsdefinitionen auch ‘Anweisungen’, die ‘ausgeführt’ werden; die Ausführung einer Funktionsdefinition auf Modulebene fügt den Funktionsnamen in die globale Symboltabelle des Moduls ein. |