(Besseres) switch/case-Pendant nun auch in Python

erinnert irgendwie an fail++. überladen mit bockmist, den man fast nie 
nutzt.

Yalu X. schrieb:
> Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und
> weniger fehlerträchtig geschrieben werden.

Naja, "ab sofort" nicht. Zumindest kann nicht jeder sofort auf das 
aktuellste Bleeding-Edge-System gehen. Ich bin ja schon froh, jetzt nur 
noch wenig mit Python 2 zu tun zu haben.

Yalu X. schrieb:
> Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und
> weniger fehlerträchtig geschrieben werden.

Der Satz hört sich an, als ob Du das ganze sarkastisch meintest. Wenn 
ich es nicht besser wüsste...


Ich finde das Konstrukt gut gelungen. Neues Schlüsselwort statt wie in
C++ zum Xten male Konstrukte zu nutzen die in alten Versionen 
Systaxfehler werfen...

Markus schrieb:
> Ich finde, daß eine ursprünglich schlanke Programmiersprache nach und
> nach mit Funktionalitäten aufgebläht wird. Nützlich sind sie durchaus,
> keine Frage, aber der Code wird mit jeder Version unübersichtlicher. Zum
> Beispiel die (optionale) Angabe der Typinformation in 3.6. Oder
> properties anstelle getter/setter (gut, das gibt es schon seit Urzeiten,
> trotzdem finde ich es unübersichtlich :-) ).

Die Typannotationen und die Properties habe ich noch nie ernsthaft
benutzt, es stört mich aber auch nicht, dass es sie gibt. Die
Typannotationen sind insofern ganz praktisch, weil damit typannotierter
Cython-Code meist ohne große Anpassungen auch im normalen Python läuft.
Da ich aber auch kein Cython benutze, ist mir das egal. Properties mag
ich generell nicht, wahrscheinlich aus demselben Grund wie du. Mit
beiden wird der Code auch nicht kürzer, eleganter oder übersichtlicher.

Beim Structural Pattern Matching ist das anders. Es ist syntaktischer
Zucker, der dazu beiträgt, komplexe, in ähnlicher Form wiederkehrende
Programmkonstrukte syntaktisch auf das Wesentliche zu reduzieren. Python
ist voll von Zucker (man denke an Dinge wie Dictionary Literals, Slice
Notation, List Comprehensions, List Unpacking u.v.m.), deswegen passt
dieses neue Feature sehr gut dazu.

Um es zu benutzen, muss man nicht viel Neues lernen: Die Schlüsselwörter
gibt es schon in C/C++/Java (nur heißt das "match" dort "switch"), die
Patterns gibt es (mit kleinen Einschränkungen) bereits im List Unpacking
und die Guards in den List Comprehensions.

Von mir aus darf Python in Zukunft noch viel mehr verzuckert werden,
denn ich mag süße Sachen ;-) Alles was dazu verhilft, aus langatmigem
Labercode etwas Kurzes, Knackiges zu machen, bei dem ich mit einem Blick
erfassen kann, was da abgeht, stößt bei mir jederzeit auf Zustimmung.

Auch Haskell wird durch den Zucker erst so richtig zu dem gemacht, was
es ist, deswegen mag ich es ebenso.

Eine Sprache mit vergleichsweise wenig Zucker ist C¹. Das mag ich auch,
denn man soll bzw. will ja nicht nur Süßes zu sich nehmen.

C++ versucht derzeit den Spagat zwischen wenig süß (à la C) und pappsüß
(à la Python), was in etwa einem Steak mit Zuckerglasur entspricht. An
diesen Geschmack habe ich mich aber immer noch nicht ganz gewöhnt ;-)


Übrigens ist Python diesen Monat im Tiobe-Index erstmals auf Platz 1
vorgerückt (knapp vor C und Java):

  https://tiobe.com/tiobe-index/

@Guido: Hau noch mehr Zucker in die Schlange und sorge dafür, dass C und
Java (vor allem letzteres) auf ihrer klebrigen Spur steckenbleiben :D

────────────
¹) aber auch hier gibt es immerhin den switch/case-Zucker

c-hater schrieb:
> Syntax-Blähungen, die die Welt nicht braucht.

Geh erst einmal auf die Toilette, um deine eigenen Blähungen, von denen
du offensichtlich gerade geplagt wirst, loszuwerden :)

> Spart im Vergleich zu einer funktionskongruenten Lösung z.B. in VB.net
> oder C# exakt eine Zeile pro Verzweigung

Kommt darauf an. C# kann Pattern Matching in Switch Expressions (aber
auch erst seit 2 Jahren), aber nicht in Switch Statements. D.h. in
den Fällen, wo man die Switch Expressions sinnvoll nutzen kann, spart
man mit dem neuen Python-Feature nur wenig bis gar keinen Code ein.

Aber darum ging es überhaupt nicht, sondern um den Vergleich mit dem
"alten" Python, wo noch nicht einmal ein klassisches switch/case gab.

Also, viel Erfolg noch auf der Toilette ...

Rolf M. schrieb:
> Zumindest kann nicht jeder sofort auf das
> aktuellste Bleeding-Edge-System gehen. Ich bin ja schon froh, jetzt nur
> noch wenig mit Python 2 zu tun zu haben.

Das geht mir beruflich leider genauso. Aber es gibt ja auch noch Hobby 
:)

Klaus H. schrieb:
> Yalu X. schrieb:
>> Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und
>> weniger fehlerträchtig geschrieben werden.
>
> Der Satz hört sich an, als ob Du das ganze sarkastisch meintest. Wenn
> ich es nicht besser wüsste...

Jetzt, wo ich den Satz noch einmal durchlese, kommt es mir auch so vor.
Vielleicht war ich vorher etwas zu euphorisch :)

> Ich finde das Konstrukt gut gelungen. Neues Schlüsselwort statt wie in
> C++ zum Xten male Konstrukte zu nutzen die in alten Versionen
> Systaxfehler werfen...

Interessanterweise bleibt die Sprache trotz der Einführung dreier neuer
Schlüsselwörter ("match", "case" und "_") abwärtskompatibel, da es sich
um sogenannte "Soft Keywords" handelt.

Lipstick on a Pig.

MaWin schrieb:
> Dieter H. schrieb:
>> den man fast nie nutzt.
>
> Ja, dann nutze es halt nicht. Wo ist das Problem?

Das Problem sind Projekte mit vielen Entwicklern bei denen jeder ein 
anderes exotisches Feature entdeckt hat und verwendet welches die 
anderen nicht kennen und verstehen.

 Michael

Egon D. schrieb:
> Wenn man mir den Nutzen nicht in zwei klaren (nicht selbst-
> bezüglichen) Sätzen erklären kann, dann brauche ich es nicht.

Der Nutzen liegt im Auge des Betrachters.

Wenn du mir überzeugend den Nutzen des für dich wichtigen Regex-Matching
in einer switch-Anweisung erklärst, werde ich es auch andersherum
versuchen :)

Allerdings brauche ich kaskadierte Regex-Abfragen so selten, dass mir
dafür eine if/elif/else-Kette mit re.match-Aufrufen völlig ausreicht.
D.h. du wirst mir auch mit 100 Sätzen den Nutzen nicht nahebringen
können ;-)

Ich vermute, dass du wenig mit zusammengesetzten Datentypen arbeitest,
so dass dir das Structural Pattern Matching nicht viel bringt und sich
der Nutzen des match/case-Konstrukts für dich auf den des klassischen
switch/case (wie in C) reduziert. Ob das alleine gegenüber einer
if/elif/else-Kette einen großen Vorteil bringt, ist Ansichtssache. Für
mich persönlich ist der Vorteil nicht sehr groß, aber groß genug, dass
ich switch/case in C oft benutze. Auch in Python werde ich deswegen das
match/case künftig nicht nur mit Pattern Matching, sondern auch C-like
nutzen.

Nur_ein_Typ schrieb:
> Yalu X. schrieb:
>> Übrigens ist Python diesen Monat im Tiobe-Index erstmals auf Platz 1
>> vorgerückt (knapp vor C und Java):
>>
>>   https://tiobe.com/tiobe-index/
>
> IIRC war das vor > zwei Jahren schon so, seitdem immer mal wieder und
> ebenso bei RedMonk und PYPL.

Nach dem Diagramm, das bis 2001 zurückreicht, hieß der Platzhirsch
bisher immer Java oder C. Allerdings dreht Tiobe öfter an den
Bewertungsschrauben, und das möglicherweise auch rückwirkend, so dass du
durchaus recht haben könntest.

Michael D. schrieb:
> Das Problem sind Projekte mit vielen Entwicklern bei denen jeder ein
> anderes exotisches Feature entdeckt hat und verwendet welches die
> anderen nicht kennen und verstehen.

Bei dem Structural Pattern Matching handelt es sich immerhin um ein
Feature, das (ähnlich wie bspw. die Typannotationen) größtenteils
selbsterklärend ist, so dass ein Entwickler, der es (noch) nicht kennt,
es zwar selber nicht benutzen wird, aber zumindest den Code seiner
Kollegen verstehen kann. Falls dadurch sein Interesse geweckt wird, wird
er sich in einer ruhigen Phase sicher mal eine Viertelstunde Zeit
nehmen, die Doku dazu zu lesen, wenn nicht, ist das auch nicht weiter
schlimm.

Das von dir angesprochene Problem ist aber grundsätzlich vorhanden, das
sehe ich genauso wie du. Das liegt ganz einfach daran, dass es kaum
jemanden gibt, der eine Programmiersprache zu 100% beherrscht.

Man könnte dadurch zu lösen versuchen, dass man die Schnittmenge der
Kenntnisse aller Beteiligten ermittelt und diese als gemeinsam zu
nutzende Untermenge der Sprache festlegt. Bei mehr als 10 Entwicklern in
einer Gruppe schrumpft diese Untermenge aber so sehr zusammen, dass man
sich softwaretechnisch leicht in die 70er Jahre zurückkatapultiert.
Außerdem muss diese Untermenge diskutiert, dokumentiert und von Zeit zu
Zeit aktualisiert werden. Das ist so viel Aufwand, dass genauso gut ein
Entwickler, der ein bestimmtes Sprach-Feature nicht versteht, das
(hoffentlich vorhandene) Lehrbuch aus dem Regal zieht und das jeweilige
Kapitel nachliest.

Nur_ein_Typ schrieb:
> Unsinn. Zu jeder sinnvolle Definition des Begriffs "Entwickler" gehört,
> daß der Betreffende sich mit seinem Handwerkszeug auskennt.

Ja, nur gibt es halt Sprachen (C++), bei denen das quasi nicht mehr 
sinnvoll moeglich ist.

Sven B. schrieb:
> Ja, nur gibt es halt Sprachen (C++), bei denen das quasi nicht mehr
> sinnvoll moeglich ist.

Java kann man da inzwischen auch dazupacken.

Noch furchtbarer ist allerdings der Trend für jeden kleinen Scheiß eine 
Fremdbibliothek einzubinden.
Der Abschuß war bei uns eine Fremdbibliothek extra nur um eine 
Datenbankverbindung "sauber" zu schließen.

Jedes kleinere Projekt besteht dann ganz schnell aus 15 und mehr 
externen Bibliotheken und man darf dann in der Lebenszeit des Produkts 
ständig auf Sicherheitsupdates oder generell darauf schauen, dass nicht 
irgendwer eine Sicherheitslücke in einer dieser libs findet und ein 
Kunde die lib dann komplett auf seine schwarze Liste setzt.

Nur_ein_Typ schrieb:
> Michael D. schrieb:
>> Das Problem sind Projekte mit vielen Entwicklern bei denen jeder ein
>> anderes exotisches Feature entdeckt hat und verwendet welches die
>> anderen nicht kennen und verstehen.
>
> Unsinn. Zu jeder sinnvolle Definition des Begriffs "Entwickler" gehört,
> daß der Betreffende sich mit seinem Handwerkszeug auskennt.

Und das gilt nicht nur für Software-Entwicklung. In den meisten Berufen 
muss man irgendwelche Werkzeuge oder Hilfsmittel benutzen, und in der 
Regel ist eigentlich jedem klar, dass man damit auch umgehen können 
muss. Nur in der Programmierung scheinen sehr viele der Meinung zu sein, 
dass Programme so geschrieben sein müssen, dass jeder, der mal für einen 
Nachmittag irgendein Tutorial im Internet gemacht hat, sie sofort 
vollständig versteht und auch selbst so implemenetieren kann.
Aktuelles C++ hat durchaus einige sehr praktische Dinge dazu bekommen, 
ist aber inzwischen auch aus meiner Sicht ausufernd komplex geworden.
Und viele Teile der Standardbibliothek wirken auf mich immer ein 
bisschen arg akademisch und weniger an praktischer Nutzung orientiert.

Udo S. schrieb:
> Noch furchtbarer ist allerdings der Trend für jeden kleinen Scheiß eine
> Fremdbibliothek einzubinden.

Das ist halt ein zweischneidiges Schwert. Jede Menge Abhängigkeiten zu 
haben, macht Sachen oft kompliziert. Alles selbst zu machen, statt auf 
existierende Lösungen zurückzugreifen, ist auch nicht das gelbe vom Ei.

> Jedes kleinere Projekt besteht dann ganz schnell aus 15 und mehr
> externen Bibliotheken und man darf dann in der Lebenszeit des Produkts
> ständig auf Sicherheitsupdates oder generell darauf schauen, dass nicht
> irgendwer eine Sicherheitslücke in einer dieser libs findet und ein
> Kunde die lib dann komplett auf seine schwarze Liste setzt.

Naja, wenn du's stattdessen selbst implementiert und dabei eine 
Sicherheitslücke eingebaut hast, kann dir das aber auch passieren. Die 
wird dann aber ggf. erst bekannt, wenn sie bei deinem Kunden bereits 
ausgenutzt wurde.

MaWin schrieb:
> Patternmatching als exotisches Feature zu bewerten, sagt einiges über
> deinen Wissensstand über den aktuellen Stand der Technik aus.

Das habe ich nicht gesagt, du reißt mein Zitat aus dem Zusammenhang.

Pattermatching verwende ich seit 1995. Perl ging nicht (das war nicht 
Bestandteil der HPUX Betriebssystem Installation) und von Python hat 
noch keiner gesprochen, d.h. ich musste awk verwenden.

> Dann müssen sie es lernen. Nennt sich Weiterbildung.

Jeder Entwickler hat andere Stärken und jeder bildet sich ständig 
weiter.
Für manche ist aber Umstieg von Windows auf Linux oder Docker know-how 
wichtiger als das neueste Feature von C++21 oder Python 3.10.

Sprachfeatures sind heutzutage nur die letzten 2%.

> Außerdem habt ihr ein Problem mit euren Prozessen, wenn jeder
> X-beliebige Entwickler einfach mal so ein Update des Python-Interpreters
> machen kann.

Ich sprach nicht von Python. Die Notwendigkeit zum Umstieg auf eine neue 
Compiler- / Interpreterversion kommt meist von externen Zwängen wie Open 
Source Libraries wie z.B. Google V8. Ansonsten durch die Behebung von 
Sicherheitslücken bzw. durch auslaufenden Support.

Das entscheidet sicher nicht ein Entwickler für sich alleine, obwohl mit 
diesen unabhängigen agilen Teams tatsächlich jeder meint er kann machen 
was er will. Da eine governance reinzubekommen muss man sich 
zurückerobern.

  Michael

MaWin schrieb:
> Michael D. schrieb:
>> und verwendet welches die
>> anderen nicht kennen und verstehen.
>
> Dann müssen sie es lernen. Nennt sich Weiterbildung.

Dabei muß man allerdings sagen, daß ausgerechnet Python sich besonders 
dadurch auszeichnet, nur sehr wenige... "exotische" Konstrukte zu haben, 
wenn ich das einmal mit anderen mir bekannten Sprachen vergleiche. Und 
sooo überraschend ist das neue Python-Feature jetzt nun wirklich nicht, 
andere Sprachen haben das ja vergleichsweise ähnlich -- wenn auch 
weniger mächtig. Insofern: ein Entwickler, der damit überfordert ist, 
hat womöglich den falschen Beruf.

MaWin schrieb:
> Ja klar,
>
> case _:
>
> statt default, otherwise, else. Ansonsten aber ganz nett.

Das hat schon seinen Sinn. Das "_" ist hier ein Schlüsselwort, das als
Wildcard dient und auch in komplizierteren Patterns verwendet werden
kann, bspw. in

1

case [3, _, x]:

Dieses Pattern matcht alle Sequenzen (bspw. Listen) mit 3 Elementen, von
denen das erste 3 und die beiden anderen beliebig sind. Das dritte
Element wird zur weiteren Verarbeitung der Variable x zugewiesen, das
zweite ist überhaupt nicht von Interesse, deswegen steht hier eine
Wildcard.

Die alleinstehende Wildcard in

1

case _:

bedeutet einfach, dass alles (d.h. jede Datenstruktur mit beliebigem
Inhalt) gematcht werden soll und kein Interesse am Inhalt besteht. Für
diesen Sonderfall ein spezielles Schlüsselwort einzuführen (wie bspw.
"default"), wäre nicht sehr sinnvoll. Bei der Notation der Wildcard als
"_" richtet sich Python nach den anderen Sprachen mit Structural Pattern
Matching (wie bspw. Haskell und Rust), wo dies ebenso gemacht wird.

Udo S. schrieb:
> Noch furchtbarer ist allerdings der Trend für jeden kleinen Scheiß

eine neue Programmierspache zu erfinden oder adaptieren.
erst Python 2/3, Icon, Java und nun Rebol
wenn auch einiges nicht für den PI gemacht wurde aber adaptiert 
offensichtlich.

MaWin schrieb:
> Nein.
>
> Das ist ähnlich unsinnig, wie bei Sprachen kein leeres Statement zu
> erlauben wir C es tut

Ein "Nein" auch von mir :)

In den meisten Programmiersprachen sind arithmetische Ausdrücke wie
bspw.

1

3 * (4 + 5)

erlaubt.

Als Sonderfall kann der Ausdruck auch aus nur einem einzelnen Wert
bestehen, bspw.

1

3

Du findest die 3 im komplizierteren Ausdruck von oben ok, im einfachen
Fall, wo der Ausdruck nur aus eine einzelnen Zahl besteht, findest du
das unsinnig und möchtest stattdessen ein neues Schlüsselwort einführen,
also so:

1

drei

Oder (vielleicht noch etwas passender, weil es ja um Wildcards geht):

1

cp *.pdf zielverzeichnis

zum Kopieren aller PDF-Dateien in ein anderes Verzeichnis ist ok, aber

1

cp * zielverzeichnis

zum Kopieren aller Dateien ist unsinnig. Dafür sollte man deiner
Ansicht nach einen neuen Befehl einführen:

1

cpall zielverzeichnis

MaWin schrieb:
> Uups, Phython is ja so doof:
>
> if i==1:
> print("nach if kein bedingtes statement")
>
> IndentationError.
>
> if i==1:
>   i=i
> print("so gehts")

Nein, die Lösung, die Python dafür hat, sieht so aus:

1

if i==1:

2

  pass

3

print("so gehts")