Zusammenfassung

Dieses PEP schlägt die Hinzufügung einer optionalen given-Klausel zu mehreren Python-Anweisungen vor, die derzeit keine zugehörige Code-Suite haben. Diese Klausel erstellt einen anweisungs-lokalen Namensraum für zusätzliche Namen, die in der zugehörigen Anweisung zugänglich sind, aber nicht Teil des enthaltenden Namensraums werden.

Die Übernahme eines neuen Symbols, ?, wird vorgeschlagen, um eine Vorwärtsreferenz auf den Namensraum zu bezeichnen, der durch die Ausführung der zugehörigen Code-Suite erstellt wird. Es wird eine Referenz auf ein types.SimpleNamespace-Objekt sein.

Die Hauptmotivation ist, einen deklarativeren Programmierstil zu ermöglichen, bei dem die auszuführende Operation dem Leser zuerst präsentiert wird und die Details der notwendigen Unterberechnungen in der folgenden eingerückten Suite dargestellt werden. Als wichtiges Beispiel würde dies gewöhnliche Zuweisungsanweisungen auf die gleiche Stufe wie class- und def-Anweisungen heben, bei denen der Name des zu definierenden Elements dem Leser vor den Details der Berechnung dieses Elements präsentiert wird. Es erlaubt auch benannte Funktionen in einer „Multi-Line-Lambda“-Art und Weise zu verwenden, wobei der Name nur als Platzhalter im aktuellen Ausdruck verwendet und dann in der folgenden Suite definiert wird.

Eine sekundäre Motivation ist die Vereinfachung von Zwischenberechnungen in Modul- und Klassencode, ohne die resultierenden Namensräume zu verunreinigen.

Die Absicht ist, dass die Beziehung zwischen einer gegebenen Klausel und einer separaten Funktionsdefinition, die die angegebene Operation ausführt, ähnlich der bestehenden Beziehung zwischen einer expliziten while-Schleife und einem Generator ist, der die gleiche Sequenz von Operationen wie diese while-Schleife erzeugt.

Der spezifische Vorschlag in diesem PEP wurde durch verschiedene Erkundungen dieser und verwandter Konzepte im Laufe der Jahre beeinflusst (z. B. [1], [2], [3], [6], [8]) und ist bis zu einem gewissen Grad von den where- und let-Klauseln in Haskell inspiriert. Er vermeidet einige Probleme, die in früheren Vorschlägen identifiziert wurden, musste sich aber selbst noch nicht dem Test der Implementierung stellen.

Vorschlag

Dieses PEP schlägt die Hinzufügung einer optionalen given-Klausel zur Syntax für einfache Anweisungen vor, die einen Ausdruck enthalten können, oder diese Anweisung aus rein syntaktischen Gründen ersetzen können. Die aktuelle Liste der einfachen Anweisungen, die von dieser Ergänzung betroffen wären, ist wie folgt:

• Ausdrucksanweisung
• Zuweisungsanweisung
• Erweiterte Zuweisungsanweisung
• del-Anweisung
• return-Anweisung
• yield-Anweisung
• raise-Anweisung
• assert-Anweisung
• pass-Anweisung

Die given-Klausel würde es ermöglichen, Unterausdrücke mit Namen in der Kopfzeile zu referenzieren, wobei die tatsächlichen Definitionen in der eingerückten Klausel folgen. Als einfaches Beispiel:

sorted_data = sorted(data, key=?.sort_key) given:
    def sort_key(item):
        return item.attr1, item.attr2

Das neue Symbol ? wird verwendet, um auf den gegebenen Namensraum zu verweisen. Es wäre eine types.SimpleNamespace-Instanz, also fungiert ?.sort_key als Vorwärtsreferenz auf einen Namen, der in der given-Klausel definiert ist.

Ein Docstring wäre in der given-Klausel zulässig und würde als __doc__-Attribut an den Ergebnisnamensraum angehängt werden.

Die pass-Anweisung ist enthalten, um eine konsistente Möglichkeit zu bieten, das Fehlen eines aussagekräftigen Ausdrucks in der Kopfzeile zu überspringen. Dies ist zwar kein beabsichtigter Anwendungsfall, aber auch keiner, der verhindert werden kann, da mehrere Alternativen (wie ... und ()) auch dann verfügbar bleiben, wenn pass selbst nicht zulässig ist.

Der Körper der given-Klausel wird in einem neuen Gültigkeitsbereich ausgeführt, unter Verwendung normaler Funktionsschluss-Semantik. Um die frühe Bindung von Schleifenvariablen und globalen Referenzen zu unterstützen, sowie um den Zugriff auf andere Namen auf Klassenebene zu ermöglichen, wird die given-Klausel auch explizite Bindungsoperationen in der Kopfzeile zulassen:

# Explicit early binding via given clause
seq = []
for i in range(10):
    seq.append(?.f) given i=i in:
        def f():
            return i
assert [f() for f in seq] == list(range(10))

op(?.f, ?.g) given bound_a=a, bound_b=b in:
    def f():
        return bound_a + bound_b
    def g():
        return bound_a - bound_b

__arg1 = a
__arg2 = b
def __scope(bound_a, bound_b):
    def f():
        return bound_a + bound_b
    def g():
        return bound_a - bound_b
   return types.SimpleNamespace(**locals())
__ref = __scope(__arg1, __arg2)
__ref.__doc__ = __scope.__doc__
op(__ref.f, __ref.g)

expr_stmt: testlist_star_expr (augassign (yield_expr|testlist) |
             ('=' (yield_expr|testlist_star_expr))*)
del_stmt: 'del' exprlist
pass_stmt: 'pass'
return_stmt: 'return' [testlist]
yield_stmt: yield_expr
raise_stmt: 'raise' [test ['from' test]]
assert_stmt: 'assert' test [',' test]

expr_stmt: testlist_star_expr (augassign (yield_expr|testlist) |
             ('=' (yield_expr|testlist_star_expr))*) [given_clause]
del_stmt: 'del' exprlist [given_clause]
pass_stmt: 'pass' [given_clause]
return_stmt: 'return' [testlist] [given_clause]
yield_stmt: yield_expr [given_clause]
raise_stmt: 'raise' [test ['from' test]] [given_clause]
assert_stmt: 'assert' test [',' test] [given_clause]
given_clause: "given" [(NAME '=' test)+ "in"]":" suite

break given:
    a = b = 1

import sys given:
    a = b = 1

stmt: simple_stmt | given_stmt | compound_stmt
simple_stmt: small_stmt (';' (small_stmt | subexpr_stmt))* [';'] NEWLINE
small_stmt: (pass_stmt | flow_stmt | import_stmt |
             global_stmt | nonlocal_stmt)
flow_stmt: break_stmt | continue_stmt
given_stmt: subexpr_stmt (given_clause |
              (';' (small_stmt | subexpr_stmt))* [';']) NEWLINE
subexpr_stmt: expr_stmt | del_stmt | flow_subexpr_stmt | assert_stmt
flow_subexpr_stmt: return_stmt | raise_stmt | yield_stmt
given_clause: "given" (NAME '=' test)* ":" suite

stmt: simple_stmt | compound_stmt
simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE
small_stmt: (expr_stmt | del_stmt | pass_stmt | flow_stmt |
             import_stmt | global_stmt | nonlocal_stmt | assert_stmt)
flow_stmt: break_stmt | continue_stmt | return_stmt | raise_stmt | yield_stmt

Begründung

Funktions- und Klassenanweisungen in Python haben eine einzigartige Eigenschaft im Vergleich zu gewöhnlichen Zuweisungsanweisungen: bis zu einem gewissen Grad sind sie *deklarativ*. Sie präsentieren dem Leser des Codes wichtige Informationen über einen Namen, der gerade definiert wird, bevor er mit den Details der eigentlichen Definition im Funktions- oder Klassenrumpf fortfährt.

Der *Name* des zu deklarierenden Objekts ist das erste, was nach dem Schlüsselwort angegeben wird. Andere wichtige Informationen erhalten ebenfalls die Ehre, den Implementierungsdetails voraus zu gehen:

• Dekoratoren (die das Verhalten des erstellten Objekts stark beeinflussen können und aus praktischen, nicht aus ästhetischen Gründen sogar vor dem Schlüsselwort und dem Namen platziert wurden)
• Der Docstring (in der ersten Zeile unmittelbar nach der Kopfzeile)
• Parameter, Standardwerte und Annotationen für Funktionsdefinitionen
• Oberklassen, Metaklasse und optional andere Details (abhängig von der Metaklasse) für Klassendefinitionen

Dieses PEP schlägt vor, einen ähnlichen deklarativen Stil für beliebige Zuweisungsoperationen verfügbar zu machen, indem eine „given“-Suite nach jeder einfachen Zuweisungsanweisung zugelassen wird.

TARGET = [TARGET2 = ... TARGETN =] EXPR given:
    SUITE

Konventionell sollte sich der Code im Rumpf der Suite ausschließlich auf die korrekte Definition der Zuweisungsoperation in der Kopfzeile konzentrieren. Die Operation in der Kopfzeile sollte ebenfalls ausreichend beschreibend sein (z. B. durch geeignete Namenswahl für Variablen), um dem Leser eine angemessene Vorstellung vom Zweck der Operation zu vermitteln, ohne den Rumpf der Suite lesen zu müssen.

Obwohl sie der anfänglich motivierende Anwendungsfall sind, wäre es übermäßig einschränkend, dieses Feature nur auf einfache Zuweisungen zu beschränken. Sobald das Feature überhaupt definiert ist, wäre es ziemlich willkürlich, seine Verwendung für erweiterte Zuweisungen, Return-Anweisungen, Yield-Ausdrücke, Comprehensions und beliebige Ausdrücke, die den Anwendungszustand modifizieren können, zu verbieten.

Die given-Klausel kann auch als lesbarere Alternative zu einigen Verwendungen von Lambda-Ausdrücken und ähnlichen Konstrukten dienen, wenn Einwegfunktionen an Operationen wie sorted() übergeben werden oder in Callback-basierter ereignisgesteuerter Programmierung.

In Modul- und Klassenebene dient die given-Klausel als klarer und zuverlässiger Ersatz für die Verwendung der del-Anweisung, um Zwischenvariablen von der Verunreinigung des resultierenden Namensraums abzuhalten.

Eine potenziell nützliche Art, die vorgeschlagene Klausel zu betrachten, ist als Mittelweg zwischen konventionellem Inline-Code und der Auslagerung einer Operation in eine dedizierte Funktion, so wie eine Inline-While-Schleife schließlich in einen dedizierten Generator ausgelagert werden kann.

Design-Diskussion

seq2 = [x for x in y if q(x) for y in seq if p(y)]

# would be equivalent to

seq2 = ?.result given seq=seq:
    result = []
    for y in seq:
        if p(y):
            for x in y:
                if q(x):
                    result.append(x)

seq2 = ?.g(seq) given:
    def g(seq):
        for y in seq:
            if p(y):
                for x in y:
                    if q(x):
                        yield x

seq2 = ? given seq=seq in:
    for y in seq:
        if p(y):
            for x in y:
                if q(x):
                    yield x

@classmethod
def classname(cls):
    return cls.__name__

classname = .d1(classname) given:
    d1 = classmethod
    def classname(cls):
        return cls.__name__

sorted_list = sorted(original, key=(lambda v: v.attr1, v.attr2))

sorted_list = sorted(original,
                     key=operator.attrgetter(v. 'attr1', 'attr2'))

def sort_key(item):
    return item.attr1, item.attr2

sorted_list = sorted(original, key=sort_key)

sorted_list = sorted(original, key=?.key) given:
    def key(item):
        return item.attr1, item.attr2

Offene Fragen

Beispiele

Definition von Callbacks für ereignisgesteuerte Programmierung

# Current Python (definition before use)
def cb(sock):
    # Do something with socket
def eb(exc):
    logging.exception(
        "Failed connecting to %s:%s", host, port)
loop.create_connection((host, port), cb, eb) given:

# Becomes:
loop.create_connection((host, port), ?.cb, ?.eb) given:
    def cb(sock):
        # Do something with socket
    def eb(exc):
        logging.exception(
            "Failed connecting to %s:%s", host, port)

Definition von „Einmaligen“ Klassen, die typischerweise nur eine einzige Instanz haben

# Current Python (instantiation after definition)
class public_name():
  ... # However many lines
public_name = public_name(*params)

# Current Python (custom decorator)
def singleton(*args, **kwds):
    def decorator(cls):
        return cls(*args, **kwds)
    return decorator

@singleton(*params)
class public_name():
  ... # However many lines

# Becomes:
public_name = ?.MeaningfulClassName(*params) given:
  class MeaningfulClassName():
    ... # Should trawl the stdlib for an example of doing this

Berechnung von Attributen ohne Verunreinigung des lokalen Namensraums (aus os.py)

# Current Python (manual namespace cleanup)
def _createenviron():
  ... # 27 line function

environ = _createenviron()
del _createenviron

# Becomes:
environ = ?._createenviron() given:
    def _createenviron():
      ... # 27 line function

Ersetzen des Standardargument-Hacks (aus functools.lru_cache)

# Current Python (default argument hack)
def decorating_function(user_function,
               tuple=tuple, sorted=sorted, len=len, KeyError=KeyError):
  ... # 60 line function
return decorating_function

# Becomes:
return ?.decorating_function given:
  # Cell variables rather than locals, but should give similar speedup
  tuple, sorted, len, KeyError = tuple, sorted, len, KeyError
  def decorating_function(user_function):
    ... # 60 line function

# This example also nicely makes it clear that there is nothing in the
# function after the nested function definition. Due to additional
# nested functions, that isn't entirely clear in the current code.

Mögliche Ergänzungen

• Der aktuelle Vorschlag erlaubt die Hinzufügung einer given-Klausel nur für einfache Anweisungen. Die Ausweitung der Idee auf die Verwendung von zusammengesetzten Anweisungen wäre durchaus möglich (durch Anhängen der given-Klausel als eigenständige Suite am Ende), aber dies birgt ernsthafte Lesbarkeitsprobleme (da Werte, die in der given-Klausel definiert sind, lange vor ihrer Definition verwendet werden können, genau die Art von Lesbarkeitsfalle, die andere Features wie Decorators und with-Anweisungen zu vermeiden suchen).
• Die Variante „explizite frühe Bindung“ könnte für die Diskussionen auf python-ideas relevant sein, wie der Standardargument-Hack eliminiert werden kann. Eine given-Klausel in der Kopfzeile für Funktionen (nach der Rückgabetypanmerkung) könnte die Antwort auf diese Frage sein.

Abgelehnte Alternativen

• Eine frühere Version dieses PEPs erlaubte implizite Vorwärtsreferenzen auf die Namen in der nachfolgenden Suite und verwendete auch implizite frühe Bindungssemantik. Beide Ideen verkomplizierten den Vorschlag erheblich, ohne eine ausreichende Steigerung der Ausdrucksstärke zu bieten. Der aktuelle Vorschlag mit expliziten Vorwärtsreferenzen und früher Bindung bringt das neue Konstrukt in Einklang mit bestehenden Gültigkeitssemantiken, was die Chancen auf eine tatsächliche Implementierung erheblich verbessert.
• Zusätzlich zu den hier gemachten Vorschlägen gab es auch Vorschläge für „In-Order“-Varianten mit zwei Suiten, die die eingeschränkte Gültigkeit von Namen bieten, ohne eine Ausführung außerhalb der Reihenfolge zu unterstützen. Ich glaube, diese Vorschläge verfehlen weitgehend den Punkt dessen, worüber sich die Leute beschweren, wenn sie nach Unterstützung für mehrzeilige Lambdas fragen – es ist nicht so, dass das Finden eines Namens für den Unterausdruck besonders schwierig ist, sondern dass die Benennung der Funktion vor der Anweisung, die sie verwendet, bedeutet, dass der Code nicht mehr mit der Art und Weise übereinstimmt, wie der Entwickler das Problem betrachtet.
• Ich habe einige unveröffentlichte Versuche unternommen, direkte Referenzen auf die Closure zu ermöglichen, die implizit durch die given-Klausel erstellt wird, während die allgemeine Struktur der Syntax wie in diesem PEP definiert bleibt (zum Beispiel, indem ein Unterausdruck wie ?given oder :given in Ausdrücken verwendet wird, um eine direkte Referenz auf die implizite Closure anzuzeigen und so zu verhindern, dass sie automatisch zur Erstellung des lokalen Namensraums aufgerufen wird). Alle solchen Versuche erschienen unattraktiv und verwirrend im Vergleich zu dem einfacheren, von Decorator inspirierten Vorschlag in PEP 403.

Referenzimplementierung

Noch keine. Wenn Sie einen Crashkurs in Python-Namensraum-Semantik und Codekompilierung wünschen, probieren Sie es gerne aus ;)

TO-DO

• Erwähnen Sie PEP 359 und mögliche Verwendungen für locals() in der given-Klausel
• Finden Sie heraus, ob dies intern verwendet werden kann, um die Implementierung von super()-Aufrufen ohne Argumente weniger schrecklich zu machen

Referenzen

• Das Designprinzip „Status quo gewinnt bei Pattstellung“
• Mehrzeilige Lambdas (schon wieder!)

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.