(match/case) keine Ahnung ob das schon gemeldet wurde, Python ist ja nicht so meins

  • Die Teilnehmer im Mikrocontroller-Forum sollen bei C oder Assembler bleiben.

    Das sind wahrscheinlich die gleichen Leute, die auch über den "Walrus-Operator" (Assignment Expression) gemeckert haben.


    Beim structural pattern matching geht es primär um eine Sache: Lesbarkeit


    Bei Python kommt es nicht auf die Geschwindigkeit zur Laufzeit an, sondern auf die Entwicklerzeit, die bei weiten kürzer ist, als bei Low-Level-Sprachen.

    Wenn der resultierende Code schlecht lesbar ist, sollte man das structural pattern matching nicht anwenden.


    Ein passender Anwendungsfall fürs structural pattern matching ist z.B. die Verarbeitung von JSON.



    Anstatt viele if..elif..else und isinstance() Aufrufe, hat man einen sauberen lesbaren Syntax.

    structural pattern matching ist weitaus mächtiger als z.B. die Switch/Case Anweisung in anderen Sprachen

    und man kann auch eigene Klassen fürs pattern matching vorbereiten.

  • Hallo,


    Quote


    ...ist weitaus mächtiger als z.B. die Switch/Case Anweisung in anderen Sprachen...

    Ergänzung: Im Vorfeld zum Release von Python 3.10 gab es ja schon einen Schwung (Blog-) Artikel dazu, die sinnvolle und nicht sinnvolle Nutzung von `match .. case` zeigen.

    Das schöne ist ja: wer's scheiße findet oder den Use-Case nicht sieht muss es nicht benutzen. Geht auch alles mit if..elif..else. Nur halt nicht immer ganz so gut lesbar.


    Gruß, noisefloor

  • DeaD_EyE Das JSON-Beispiel ist mit ``match``/``case`` nicht wirklich besser als die herkömmliche Variante:

    Python
    def get_users(json_data):
        return json.loads(json_data).get("users", [])

    Dass das „soft keywords“ sind, ist blöd für's Syntax-Highlighting, weil das plötzlich deutlich intelligenter sein muss. Die Grammatik ist auch nicht mehr so leicht zu parsen, weil man nicht mehr beim Vorausschauen mit *einem* Token entscheiden kann, wie's nun weitergehen muss. Das ist was das gabs früher schon mal und da wollten die Leute dringend von weg, weil das doof ist. Das parsen ist aufwändiger und man baut sich leichter Fehler/Mehrdeutigkeiten ein, die man dann irgendwie wieder lösen muss.


    Und es öffnet die Tür jetzt für alles mögliche neue Schlüsselwörter einzuführen, was vorher eine praktische Grenze war, die die Sprache einfach hält.


    noisefloor Mit dem benutzen müssen ist das so eine Sache. Wenn andere das in ihren Code schreiben, muss ich das am Ende lesen und verstehen. Und dann auch darunter leiden, dass viele Dinge aus anderen Programmiersprachen unbedingt irgendwie mit Gewalt in Python quetschen wollen. Zu ``public``/``private``/``protected`` wird jetzt noch ``switch``/``case`` aus Sprache X (vornehmlich die, wo auch ``private`` her kommt) ist jetzt auch in Python und heisst dort ``match``/``case``. Und dann kommen die Fragen, warum das Konstrukt nicht funktioniert und Konstanten umbenennt, oder so komische Syntaxfehler produziert. Naja, weil es eben kein ``switch``/``case`` ist, sondern strukturelles Pattern-Matching.


    Die Typannotationen werden einem auch ungewollt immer wieder aufgedrängt. Zum Beispiel bei `dataclasses`.

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra

  • DeaD_EyE Das JSON-Beispiel ist mit ``match``/``case`` nicht wirklich besser als die herkömmliche Variante:

    Das ist dein Geschmack. Ich mag Grün viel lieber...



    Dass das „soft keywords“ sind, ist blöd für's Syntax-Highlighting, weil das plötzlich deutlich intelligenter sein muss.


    Und es öffnet die Tür jetzt für alles mögliche neue Schlüsselwörter einzuführen, was vorher eine praktische Grenze war, die die Sprache einfach hält.

    Die Logik ist bereits bei PyCharm mit drin und das sogar vor dem Release von Python 3.10.0.

    Dank des neuen PEG Parsers werden wir sicherlich noch weitere solcher schönen Veränderungen bekommen.


    Die Typannotationen werden einem auch ungewollt immer wieder aufgedrängt. Zum Beispiel bei `dataclasses`.

    Ich bin froh, dass es sie gibt. Wenn man moderne Frameworks wie FastAPI nutzt, führt ohnehin kein Weg dran vorbei.

  • PyCharm ist irgendwie nicht der einzige Syntax-Highlighter. Und das benutzt auch nicht jeder. Und nicht überall kann/will man sich jetzt ”teure” Parser für so etwas leisten. Wie gut das dann beispielsweise bei Highlightern beispielsweise in Foren funktionieren wird, wird interessant. Die verstehen im Gegensatz zu einer IDE ja deutlich weniger von der Sprache und sind meistens auch nicht *soo* flexibel was die Beschreibung einer Grammatik angeht.


    Mal sehen wie sich die Anzeige von so etwas hier in Zukunft entwickeln wird:

    Python
    for case in cases:
        match case:
            case {"match": match}:
                print(case, "contains", match)

    Erinnert ein bisschen an Sprachen die so etwas erlauben: IF ELSE = THEN THEN ELSE := IF ELSE ELSE := THEN + 1; 🤓

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra