Alternative 1

Dies ist die bevorzugte Form in PEP 275

switch EXPR:
    case EXPR:
        SUITE
    case EXPR:
        SUITE
    ...
    else:
        SUITE

Der Hauptnachteil ist, dass die Suiten, in denen die eigentliche Aktion stattfindet, zwei Ebenen tief eingerückt sind; dies kann durch Einrücken der Fälle um "einen halben Level" behoben werden (z. B. 2 Leerzeichen, wenn die allgemeine Einrückungsebene 4 beträgt).

Alternative 2

Dies ist die bevorzugte Form von Fredrik Lundh; sie unterscheidet sich dadurch, dass die Fälle nicht eingerückt werden

switch EXPR:
case EXPR:
    SUITE
case EXPR:
    SUITE
....
else:
    SUITE

Einige Gründe, diese nicht zu wählen, sind erwartete Schwierigkeiten für Auto-Einrückungseditoren, Falten-Editoren und dergleichen; und verwirrte Benutzer. Derzeit gibt es in Python keine Situationen, in denen eine Zeile, die mit einem Doppelpunkt endet, von einer nicht eingerückten Zeile gefolgt wird.

Alternative 3

Dies ist dasselbe wie Alternative 2, lässt jedoch den Doppelpunkt nach dem Switch weg

switch EXPR
case EXPR:
    SUITE
case EXPR:
    SUITE
....
else:
    SUITE

Die Hoffnung dieser Alternative ist, dass sie die Auto-Einrückungslogik des durchschnittlichen Python-bewussten Texteditors weniger stört. Aber sie sieht für mich seltsam aus.

Alternative 4

Dies lässt das Schlüsselwort 'case' weg, da es redundant ist

switch EXPR:
    EXPR:
        SUITE
    EXPR:
        SUITE
    ...
    else:
        SUITE

Leider sind wir nun gezwungen, die Case-Ausdrücke einzurücken, da ansonsten (zumindest in Abwesenheit des Schlüsselworts 'else') der Parser Schwierigkeiten hätte zu unterscheiden, ob ein nicht eingerückter Case-Ausdruck (der die Switch-Anweisung fortsetzt) oder eine unabhängige Anweisung ist, die wie ein Ausdruck beginnt (z. B. eine Zuweisung oder ein Prozeduraufruf). Der Parser ist nicht intelligent genug, um zurückzuspulen, sobald er den Doppelpunkt sieht. Dies ist meine am wenigsten bevorzugte Alternative.

Alternative A

Verwenden Sie

case EXPR:

um auf einen einzelnen Ausdruck zu prüfen; verwenden Sie

case EXPR, EXPR, ...:

um auf mehrere Ausdrücke zu prüfen. Das wird so interpretiert, dass, wenn EXPR ein geklammerter Tupel oder ein anderer Ausdruck ist, dessen Wert ein Tupel ist, der Switch-Ausdruck gleich diesem Tupel sein muss, nicht einem seiner Elemente. Das bedeutet, dass wir keine Variable verwenden können, um mehrere Fälle anzuzeigen. Während dies auch in C's Switch-Anweisung der Fall ist, ist es in Python relativ häufig vorkommend (siehe zum Beispiel sre_compile.py).

Alternative B

Verwenden Sie

case EXPR:

um auf einen einzelnen Ausdruck zu prüfen; verwenden Sie

case in EXPR_LIST:

um auf mehrere Ausdrücke zu prüfen. Wenn EXPR_LIST ein einzelner Ausdruck ist, zwingt das 'in' seine Interpretation als ein Iterable (oder etwas, das __contains__ unterstützt, in einer Minderheiten-Semantik-Alternative). Wenn es mehrere Ausdrücke sind, wird jeder davon für eine Übereinstimmung betrachtet.

Alternative C

Verwenden Sie

case EXPR:

um auf einen einzelnen Ausdruck zu prüfen; verwenden Sie

case EXPR, EXPR, ...:

um auf mehrere Ausdrücke zu prüfen (wie in Alternative A); und verwenden Sie

case *EXPR:

um auf die Elemente eines Ausdrucks zu prüfen, dessen Wert ein Iterable ist. Die beiden letzteren Fälle können kombiniert werden, so dass die tatsächliche Syntax eher so aussieht

case [*]EXPR, [*]EXPR, ...:

Die Notation mit dem * ähnelt der Verwendung des Präfixes *, das bereits für Parameterlisten variabler Länge und für die Übergabe berechneter Argumentlisten verwendet wird und oft für die Wertentpackung vorgeschlagen wird (z. B. a, b, *c = X als Alternative zu X[:2], X[2:]).

Alternative D

Dies ist eine Mischung aus den Alternativen B und C; die Syntax ist wie Alternative B, verwendet aber anstelle des Schlüsselworts 'in' ein '*'. Dies ist begrenzter, erlaubt aber immer noch die gleiche Flexibilität. Es verwendet

case EXPR:

um auf einen einzelnen Ausdruck zu prüfen und

case *EXPR:

um auf die Elemente eines Iterables zu prüfen. Wenn man mehrere Übereinstimmungen in einem Fall angeben möchte, kann man dies so schreiben

case *(EXPR, EXPR, ...):

oder vielleicht so (obwohl es etwas seltsam ist, da die relative Priorität von '*' und ',' anders ist als anderswo)

case * EXPR, EXPR, ...:

Diskussion

Die Alternativen B, C und D sind motiviert durch den Wunsch, mehrere Fälle mit der gleichen Behandlung durch eine Variable zu spezifizieren, die eine Menge (typischerweise ein Tupel) repräsentiert, anstatt sie buchstäblich aufzulisten. Die Motivation dafür ist normalerweise, dass es schade ist, wenn man mehrere Switches über dieselben Fälle hat, alle Alternativen jedes Mal aufzählen zu müssen. Eine zusätzliche Motivation ist die Möglichkeit, *Bereiche* einfach und effizient abzugleichen, ähnlich der Pascalschen "1..1000:"-Notation. Gleichzeitig wollen wir die Art von Fehlern verhindern, die bei der Ausnahmebehandlung üblich sind (und die in Python 3000 durch Änderung der Syntax der except-Klausel behoben werden): Schreiben von "case 1, 2:" anstelle von "case (1, 2):" oder umgekehrt.

Man könnte argumentieren, dass der Bedarf nicht ausreichend für die zusätzliche Komplexität ist; C hat keine Möglichkeit, Bereiche auszudrücken, und es wird heutzutage viel mehr verwendet als Pascal. Außerdem könnten bei einer Dispatch-Methode, die auf Dict-Lookup basiert, große Bereiche ineffizient sein (betrachten Sie range(1, sys.maxint)).

Alles in allem sind meine Präferenzen (von der am meisten zur am wenigsten bevorzugten) B, A, D', C, wobei D' D ohne die dritte Möglichkeit ist.

If/Elif-Kette vs. Dict-basierter Dispatch

Es gibt mehrere Hauptdenkschulen bezüglich der Semantik der Switch-Anweisung

• Schule I möchte die Switch-Anweisung im Sinne einer äquivalenten if/elif-Kette definieren (möglicherweise mit einigen Optimierungen).
• Schule II zieht es vor, sie als Dispatch auf ein vorab berechnetes Dict zu betrachten. Es gibt verschiedene Entscheidungen, wann die Vorberechnung stattfindet.
• Es gibt auch Schule III, die mit Schule I darin übereinstimmt, dass die Definition einer Switch-Anweisung im Sinne einer äquivalenten if/elif-Kette erfolgen sollte, aber dem Optimierungslager zugesteht, dass alle beteiligten Ausdrücke hashbar sein müssen.

Wir müssen Schule I weiter in Schule Ia und Schule Ib unterteilen

• Schule Ia hat eine einfache Position: Eine Switch-Anweisung wird in eine äquivalente if/elif-Kette übersetzt, und das ist alles. Sie sollte nicht mit Optimierung in Verbindung gebracht werden. Das ist auch mein Hauptargument gegen diese Schule: Ohne jeglichen Hinweis auf Optimierung ist die Switch-Anweisung nicht attraktiv genug, um neue Syntax zu rechtfertigen.
• Schule Ib hat eine komplexere Position: Sie stimmt mit Schule II überein, dass Optimierung wichtig ist, und ist bereit, dem Compiler gewisse Freiheiten einzuräumen, um dies zu ermöglichen. (Zum Beispiel PEP 275 Lösung 1.) Insbesondere können hash() des Switches und der Case-Ausdrücke möglicherweise nicht aufgerufen werden (daher sollten sie nebenwirkungsfrei sein); und die Case-Ausdrücke dürfen nicht jedes Mal ausgewertet werden, wie es das if/elif-Kettenverhalten erwartet, daher sollten auch die Case-Ausdrücke nebenwirkungsfrei sein. Mein Einwand dagegen (weiter unten ausgeführt) ist, dass, wenn entweder hash() oder die Case-Ausdrücke nicht nebenwirkungsfrei sind, optimierter und nicht optimierter Code unterschiedlich verhalten kann.

Schule II entstand aus der Erkenntnis, dass die Optimierung häufig vorkommender Fälle nicht so einfach ist und dass es besser ist, sich dem direkt zu stellen. Dies wird weiter unten deutlich.

Die Unterschiede zwischen Schule I (hauptsächlich Schule Ib) und Schule II sind dreifach

• Bei der Optimierung mit einem Dispatch-Dict muss, wenn entweder der Switch-Ausdruck oder die Case-Ausdrücke unhashbar sind (in diesem Fall löst hash() eine Ausnahme aus), Schule Ib das hash()-Fehlerschlagen abfangen und auf eine if/elif-Kette zurückgreifen. Schule II lässt einfach die Ausnahme geschehen. Das Problem beim Abfangen einer Ausnahme in hash() wie von Schule Ib gefordert, ist, dass dies einen echten Fehler verbergen kann. Ein möglicher Ausweg ist, nur dann ein Dispatch-Dict zu verwenden, wenn alle Case-Ausdrücke ints, Strings oder andere eingebaute Typen mit bekannt gutem Hash-Verhalten sind, und nur dann zu versuchen, den Switch-Ausdruck zu hashen, wenn er ebenfalls von diesem Typ ist. Typobjekte sollten hier wahrscheinlich auch unterstützt werden. Dies ist das (einzige) Problem, das Schule III behandelt.
• Bei der Optimierung mit einem Dispatch-Dict liefert die hash()-Funktion eines beteiligten Ausdrucks einen falschen Wert, und unter Schule Ib verhält sich der optimierte Code nicht wie der nicht optimierte Code. Dies ist ein bekanntes Problem mit optimierungsbezogenen Fehlern und verschwendet viel Entwicklerzeit. Unter Schule II werden in dieser Situation falsche Ergebnisse zumindest konsistent produziert, was die Fehlersuche etwas erleichtern sollte. Der für den vorherigen Punkt vorgeschlagene Ausweg würde hier auch helfen.
• Schule Ib hat keine gute Optimierungsstrategie, wenn die Case-Ausdrücke benannte Konstanten sind. Der Compiler kann ihre Werte nicht sicher kennen und er kann nicht wissen, ob sie wirklich konstant sind. Als Ausweg wurde vorgeschlagen, den Ausdruck, der dem Case entspricht, neu auszuwerten, sobald das Dict ermittelt hat, welcher Case genommen werden soll, um zu überprüfen, ob sich der Wert des Ausdrucks nicht geändert hat. Aber streng genommen müssten auch alle Case-Ausdrücke vor diesem Case überprüft werden, um die echte if/elif-Ketten-Semantik zu bewahren, was die Optimierung vollständig zunichtemachen würde. Eine andere vorgeschlagene Lösung ist, Callbacks zu haben, die das Dispatch-Dict über Änderungen am Wert von Variablen oder Attributen informieren, die an den Case-Ausdrücken beteiligt sind. Dies ist jedoch im Allgemeinen nicht implementierbar und würde viele Namensräume dazu zwingen, die Unterstützung für solche Callbacks zu tragen, die derzeit überhaupt nicht existieren.
• Schließlich gibt es Meinungsverschiedenheiten bezüglich der Behandlung von doppelten Fällen (d. h. zwei oder mehr Fälle mit Übereinstimmungsausdrücken, die denselben Wert ergeben). Schule I möchte dies so behandeln, wie eine if/elif-Kette es tun würde (d. h. die erste Übereinstimmung gewinnt und der Code für die zweite Übereinstimmung ist stillschweigend unerreichbar); Schule II möchte, dass dies ein Fehler zum Zeitpunkt des Einfrierens des Dispatch-Dicts ist (so dass toter Code nicht unentdeckt bleibt).

Schule I sieht Probleme im Ansatz von Schule II des Voreinfrierens eines Dispatch-Dicts, da dies Programmierern eine neue und ungewöhnliche Belastung auferlegt, genau zu verstehen, welche Arten von Case-Werten eingefroren werden dürfen und wann die Case-Werte eingefroren werden, da sie sonst vom Verhalten der Switch-Anweisung überrascht werden könnten.

Schule II glaubt nicht, dass der unoptimierte Switch von Schule Ia die Mühe wert ist, und sie sieht Probleme im Optimierungsvorschlag von Schule Ib, der dazu führen kann, dass optimierter und nicht optimierter Code unterschiedlich verhalten.

Darüber hinaus sieht Schule II wenig Wert darin, Fälle mit unhashbaren Werten zuzulassen; wenn der Benutzer solche Werte erwartet, kann er genauso gut eine if/elif-Kette schreiben. Schule II glaubt auch nicht, dass es richtig ist, toten Code aufgrund überlappender Fälle unbezeichnet zu lassen, wenn die Dict-basierte Dispatch-Implementierung es so einfach macht, dies zu erkennen.

Es gibt jedoch einige Anwendungsfälle für überlappende/doppelte Fälle. Angenommen, Sie schalten auf einigen OS-spezifischen Konstanten (z. B. exportiert vom os-Modul oder einem ähnlichen Modul). Sie haben einen Fall für jeden. Aber auf einigen OS haben zwei verschiedene Konstanten denselben Wert (da sie auf diesem OS auf die gleiche Weise implementiert sind – wie O_TEXT und O_BINARY unter Unix). Wenn doppelte Fälle als Fehler markiert werden, würde Ihr Switch auf diesem OS überhaupt nicht funktionieren. Es wäre viel besser, wenn Sie die Fälle so anordnen könnten, dass ein Fall Vorrang vor einem anderen hat.

Es gibt auch den (wahrscheinlichereren) Anwendungsfall, bei dem Sie eine Menge von Fällen haben, die gleich behandelt werden sollen, aber ein Mitglied der Menge muss anders behandelt werden. Es wäre praktisch, die Ausnahme in einem früheren Fall zu platzieren und es dabei zu belassen.

(Ja, es scheint schade zu sein, toten Code aufgrund versehentlicher Fallduplizierung nicht diagnostizieren zu können. Vielleicht ist das weniger wichtig, und pychecker kann damit umgehen? Schließlich diagnostizieren wir auch keine doppelten Methodendefinitionen.)

Dies deutet auf Schule IIb hin: wie Schule II, aber redundante Fälle müssen durch Wahl der ersten Übereinstimmung aufgelöst werden. Dies ist trivial zu implementieren, wenn das Dispatch-Dict erstellt wird (Schlüssel überspringen, die bereits vorhanden sind).

(Eine Alternative wäre die Einführung neuer Syntax, um "überlappende Fälle sind in Ordnung" oder "dieser Fall ist toter Code, wenn er nicht berücksichtigt wird" anzuzeigen, aber das halte ich für übertrieben.)

Persönlich gehöre ich zu Schule II: Ich glaube, dass der Dict-basierte Dispatch die einzig wahre Implementierung für Switch-Anweisungen ist und dass wir die Einschränkungen von vorneherein angehen sollten, damit wir maximalen Nutzen ziehen können. Ich neige zu Schule IIb – doppelte Fälle sollten durch die Reihenfolge der Fälle aufgelöst werden und nicht als Fehler markiert werden.

Wann soll das Dispatch-Dict eingefroren werden?

Für Befürworter von Schule II (Dict-basierter Dispatch) ist das nächste große Spaltungsthema, wann das für das Schalten verwendete Dict erstellt wird. Ich nenne das "Einfrieren des Dicts".

Das Hauptproblem, das dies interessant macht, ist die Beobachtung, dass Python keine benannten Compile-Zeit-Konstanten hat. Was konzeptionell eine Konstante ist, wie z. B. re.IGNORECASE, ist für den Compiler eine Variable, und nichts hindert schurkisches Verhalten daran, ihren Wert zu ändern.

def foo(x, y):
    switch x:
    case y:
        print 42

def foo(x, y):
    if x == y:
        print 42