Zusammenfassung

In den meisten Sprachen, die verschachtelte Gültigkeitsbereiche unterstützen, kann Code auf jeden Namen im nächstgelegenen umschließenden Gültigkeitsbereich zugreifen oder diesen neu binden (zuweisen). Derzeit kann Python-Code auf einen Namen in jedem umschließenden Gültigkeitsbereich zugreifen, aber nur Namen in zwei Gültigkeitsbereichen neu binden: dem lokalen Gültigkeitsbereich (durch einfache Zuweisung) oder dem Modul-Globalen-Gültigkeitsbereich (mittels einer global-Deklaration).

Diese Einschränkung wurde viele Male auf der Python-Dev-Mailingliste und anderswo angesprochen und hat zu ausgedehnten Diskussionen und vielen Vorschlägen zur Beseitigung dieser Einschränkung geführt. Dieses PEP fasst die verschiedenen vorgeschlagenen Alternativen zusammen, zusammen mit den für jede genannten Vor- und Nachteile.

Begründung

Vor Version 2.1 ähnelte Pythons Behandlung von Gültigkeitsbereichen der von Standard-C: Innerhalb einer Datei gab es nur zwei Ebenen von Gültigkeitsbereichen, global und lokal. In C ist dies eine natürliche Folge der Tatsache, dass Funktionsdefinitionen nicht verschachtelt werden können. Aber in Python, obwohl Funktionen normalerweise auf der obersten Ebene definiert werden, kann eine Funktionsdefinition überall ausgeführt werden. Dies gab Python das syntaktische Aussehen einer verschachtelten Gültigkeitsbereichsregel, aber nicht die Semantik, und führte zu Inkonsistenzen, die für einige Programmierer überraschend waren – zum Beispiel würde eine rekursive Funktion, die auf der obersten Ebene funktionierte, aufhören zu funktionieren, wenn sie in eine andere Funktion verschoben würde, da der Name der rekursiven Funktion in ihrem eigenen Gültigkeitsbereich nicht mehr sichtbar wäre. Dies verletzt die Intuition, dass eine Funktion sich konsistent verhalten sollte, wenn sie in verschiedenen Kontexten platziert wird. Hier ist ein Beispiel

def enclosing_function():
    def factorial(n):
        if n < 2:
            return 1
        return n * factorial(n - 1)  # fails with NameError
    print factorial(5)

Python 2.1 näherte sich statisch verschachtelten Gültigkeitsbereichen an, indem es die Namen sichtbar machte, die in allen umschließenden Gültigkeitsbereichen gebunden sind (siehe PEP 227). Diese Änderung bewirkt, dass das obige Codebeispiel wie erwartet funktioniert. Da jedoch jede Zuweisung an einen Namen diesen Namen implizit als lokal deklariert, ist es unmöglich, einen Namen in einem äußeren Gültigkeitsbereich neu zu binden (es sei denn, eine global-Deklaration erzwingt, dass der Name global ist). Somit funktioniert der folgende Code, der eine Zahl anzeigen soll, die durch Klicken auf Schaltflächen erhöht und verringert werden kann, nicht wie jemand, der mit lexikalischer Gültigkeitsbereichsregel vertraut ist, erwarten würde

def make_scoreboard(frame, score=0):
    label = Label(frame)
    label.pack()
    for i in [-10, -1, 1, 10]:
        def increment(step=i):
            score = score + step  # fails with UnboundLocalError
            label['text'] = score
        button = Button(frame, text='%+d' % i, command=increment)
        button.pack()
    return label

Pythons Syntax bietet keine Möglichkeit anzuzeigen, dass der Name score, der in increment erwähnt wird, sich auf die Variable score bezieht, die in make_scoreboard gebunden ist, und nicht auf eine lokale Variable in increment. Benutzer und Entwickler von Python haben Interesse bekundet, diese Einschränkung zu beseitigen, damit Python die volle Flexibilität des Algol-artigen Gültigkeitsbereichsmodells erhalten kann, das in vielen Programmiersprachen, einschließlich JavaScript, Perl, Ruby, Scheme, Smalltalk, C mit GNU-Erweiterungen und C# 2.0, Standard ist.

Es wurde argumentiert, dass eine solche Funktion nicht notwendig sei, da eine neu bindbare äußere Variable durch Einpacken in ein mutierbares Objekt simuliert werden kann

class Namespace:
    pass

def make_scoreboard(frame, score=0):
    ns = Namespace()
    ns.score = 0
    label = Label(frame)
    label.pack()
    for i in [-10, -1, 1, 10]:
        def increment(step=i):
            ns.score = ns.score + step
            label['text'] = ns.score
        button = Button(frame, text='%+d' % i, command=increment)
        button.pack()
    return label

Dieser Workaround hebt jedoch nur die Mängel bestehender Gültigkeitsbereiche hervor: Der Zweck einer Funktion ist es, Code in ihrem eigenen Namensraum zu kapseln, daher erscheint es bedauerlich, dass der Programmierer zusätzliche Namensräume erstellen muss, um fehlende Funktionalität in den bestehenden lokalen Gültigkeitsbereichen auszugleichen, und dann entscheiden muss, ob jeder Name im realen oder simulierten Gültigkeitsbereich angesiedelt werden soll.

Ein weiterer häufiger Einwand ist, dass die gewünschte Funktionalität auch als Klasse implementiert werden kann, wenn auch etwas umständlicher. Eine Erwiderung auf diesen Einwand ist, dass die Existenz eines anderen Implementierungsstils kein Grund ist, ein unterstütztes Programmierkonstrukt (verschachtelte Gültigkeitsbereiche) funktional unvollständig zu lassen. Python wird manchmal als „Multi-Paradigma-Sprache“ bezeichnet, da es aus seiner Unterstützung und seiner anmutigen Integration mehrerer Programmierparadigmen so viel Stärke, praktische Flexibilität und pädagogische Kraft schöpft.

Ein Vorschlag für die Syntax von Gültigkeitsbereichen erschien bereits 1994 auf Python-Dev [1], lange bevor PEP 227 zur Unterstützung von verschachtelten Gültigkeitsbereichen angenommen wurde. Damals war Guidos Antwort

Dies ist gefährlich nahe an der Einführung von CSNS [klassische statische verschachtelte Gültigkeitsbereiche]. *Wenn* Sie dies tun würden, scheinen Ihre vorgeschlagenen Semantiken für Gültigkeitsbereiche in Ordnung. Ich glaube immer noch, dass es nicht genug Bedarf für CSNS gibt, um diese Art von Konstrukt zu rechtfertigen …

Nach PEP 227 ist die „Diskussion über die Neubindung äußerer Namen“ oft genug auf Python-Dev wieder aufgetaucht, dass sie zu einem vertrauten Ereignis geworden ist, das seit mindestens 2003 in seiner jetzigen Form wiederkehrt [2]. Obwohl bisher keine der in diesen Diskussionen vorgeschlagenen Sprachänderungen übernommen wurde, hat Guido anerkannt, dass eine Sprachänderung eine Überlegung wert ist [12].

Andere Sprachen

Zur Hintergrundinformation beschreibt dieser Abschnitt, wie einige andere Sprachen verschachtelte Gültigkeitsbereiche und Neubindungen behandeln.

Übersicht der Vorschläge

Es gab viele verschiedene Vorschläge auf Python-Dev für Möglichkeiten, Namen in äußeren Gültigkeitsbereichen neu zu binden. Sie fallen alle in zwei Kategorien: neue Syntax in dem Gültigkeitsbereich, in dem der Name gebunden ist, oder neue Syntax in dem Gültigkeitsbereich, in dem der Name verwendet wird.

setter1 = proc { | x | y = x }      # y is local here
y = 13
setter2 = proc { | x | y = x }      # y is nonlocal here
setter1.call(99)
puts y                              # prints 13
setter2.call(77)
puts y                              # prints 77

Vorgeschlagene Lösung

Die von diesem PEP vorgeschlagene Lösung ist die Hinzufügung einer Deklaration zur Überschreibung des Gültigkeitsbereichs im referenzierenden (inneren) Gültigkeitsbereich. Guido hat seine Präferenz für diese Kategorie von Lösungen auf Python-Dev geäußert [14] und nonlocal als Schlüsselwort befürwortet [19].

Die vorgeschlagene Deklaration

nonlocal x

verhindert, dass x im aktuellen Gültigkeitsbereich zu einem lokalen Namen wird. Alle Vorkommen von x im aktuellen Gültigkeitsbereich beziehen sich auf das in einem äußeren umschließenden Gültigkeitsbereich gebundene x. Wie bei global sind mehrere Namen zulässig

nonlocal x, y, z

Wenn keine vorhandene Bindung in einem umschließenden Gültigkeitsbereich existiert, löst der Compiler einen `SyntaxError` aus. (Es mag eine Überdehnung sein, dies als Syntaxfehler zu bezeichnen, aber bisher wird `SyntaxError` für alle Fehler zur Kompilierungszeit verwendet, einschließlich beispielsweise `__future__` import mit einem unbekannten Feature-Namen.) Guido hat gesagt, dass diese Art von Deklaration in Abwesenheit einer äußeren Bindung als Fehler betrachtet werden sollte [16].

Wenn eine nonlocal-Deklaration mit dem Namen eines formalen Parameters im lokalen Gültigkeitsbereich kollidiert, löst der Compiler einen `SyntaxError` aus.

Eine Kurzform ist ebenfalls zulässig, bei der nonlocal einer Zuweisung oder einer erweiterten Zuweisung vorangestellt wird

nonlocal x = 3

Das Obige hat exakt die gleiche Bedeutung wie nonlocal x; x = 3. (Guido unterstützt eine ähnliche Form der global-Anweisung [24].)

Auf der linken Seite der Kurzform sind nur Bezeichner erlaubt, keine Zielausdrücke wie x[0]. Ansonsten sind alle Formen der Zuweisung erlaubt. Die vorgeschlagene Grammatik der nonlocal-Anweisung ist

nonlocal_stmt ::=
    "nonlocal" identifier ("," identifier)*
               ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

Der Grund für die Zulassung all dieser Zuweisungsformen liegt darin, dass sie das Verständnis der nonlocal-Anweisung vereinfacht. Die Trennung der Kurzform in eine Deklaration und eine Zuweisung reicht aus, um zu verstehen, was sie bedeutet und ob sie gültig ist.

Abwärtskompatibilität

Dieses PEP zielt auf Python 3000 ab, wie von Guido vorgeschlagen [19]. Andere haben jedoch angemerkt, dass einige in diesem PEP berücksichtigte Optionen kleine Änderungen sein könnten, die in Python 2.x machbar sind [26], in diesem Fall könnte dieses PEP möglicherweise zu einem PEP der 2.x-Reihe werden.

Als (sehr grobe) Messung der Auswirkungen der Einführung eines neuen Schlüsselworts ist hier die Anzahl der Male, die einige der vorgeschlagenen Schlüsselwörter als Bezeichner in der Standardbibliothek vorkommen, gemäß einer Analyse des Python SVN-Repositorys vom 5. November 2006

nonlocal    0
use         2
using       3
reuse       4
free        8
outer     147

global erscheint 214 Mal als bestehendes Schlüsselwort. Als Maß für die Auswirkung der Verwendung von global als Schlüsselwort für den äußeren Gültigkeitsbereich gibt es 18 Dateien in der Standardbibliothek, die als Ergebnis einer solchen Änderung fehlschlagen würden (da eine Funktion eine Variable als global deklariert, bevor diese Variable im globalen Gültigkeitsbereich eingeführt wurde)

cgi.py
dummy_thread.py
mhlib.py
mimetypes.py
idlelib/PyShell.py
idlelib/run.py
msilib/__init__.py
test/inspect_fodder.py
test/test_compiler.py
test/test_decimal.py
test/test_descr.py
test/test_dummy_threading.py
test/test_fileinput.py
test/test_global.py (not counted: this tests the keyword itself)
test/test_grammar.py (not counted: this tests the keyword itself)
test/test_itertools.py
test/test_multifile.py
test/test_scope.py (not counted: this tests the keyword itself)
test/test_threaded_import.py
test/test_threadsignals.py
test/test_warnings.py

Referenzen

[15] Explicit Lexical Scoping (pre-PEP?) (Guido van Rossum) https://mail.python.org/pipermail/python-dev/2006-July/066995.html

Danksagungen

Die in diesem PEP genannten Ideen und Vorschläge stammen aus unzähligen Python-Dev-Beiträgen. Danke an Jim Jewett, Mike Orr, Jason Orendorff und Christian Tanzer für die Vorschläge spezifischer Bearbeitungen dieses PEP.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.