Vorweg: Ich bin von diesem neuen Python-Feature so begeistert, dass ich
dies hier einfach loswerden muss. Wer es schon kennt oder von Python
sowieso nichts hält, braucht nicht weiterzulesen :)
Es hat über 30 Jahre gedauert, nun (in Version 3.10 von letzter Woche)
ist das Konstrukt in Form von match/case endlich da.
Das "match" deutet schon an, dass es mehr ist als das switch/case in
C/C++, denn als Vergleichswert nach jedem case-Schlüsselwort kann nicht
nur eine einfache Konstante, sondern ein "structural Pattern" mit
optionalem "Guard" stehen, wie man es von Haskell und einigen neueren
Programmiersprachen (bspw. Rust und Scala) kennt.
Was das bedeutet und wofür es nützlich ist, wird in diesem Tutorial
anhand von Beispielen gezeigt:
https://www.python.org/dev/peps/pep-0636/
Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und
weniger fehlerträchtig geschrieben werden.
Yalu X. schrieb:> Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und> weniger fehlerträchtig geschrieben werden.
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 :-) ).
Yalu X. schrieb:> Das "match" deutet schon an, dass es mehr ist als das> switch/case in C/C++, denn als Vergleichswert nach> jedem case-Schlüsselwort kann nicht nur eine einfache> Konstante, sondern ein "structural Pattern" mit> optionalem "Guard" stehen, wie man es von Haskell und> einigen neueren Programmiersprachen (bspw. Rust und> Scala) kennt.
Hmm.
Funktioniert das so ähnlich wie in Tcl, wo das "Pattern"
in jedem Zweig des "switch" auch ein regulärer Ausdruck
sein kann?
Egon D. schrieb:> Funktioniert das so ähnlich wie in Tcl, wo das "Pattern"> in jedem Zweig des "switch" auch ein regulärer Ausdruck> sein kann?
Nein. Es funktioniert in etwa so, wie match auch in anderen modernen
Sprachen funktioniert. Zum Beispiel wie in Rust.
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:> Das "match" deutet schon an, dass es mehr ist als das switch/case in> C/C++, denn als Vergleichswert nach jedem case-Schlüsselwort kann nicht> nur eine einfache Konstante, sondern ein "structural Pattern" mit> optionalem "Guard" stehen, wie man es von Haskell und einigen neueren> Programmiersprachen (bspw. Rust und Scala) kennt.
Syntax-Blähungen, die die Welt nicht braucht.
Spart im Vergleich zu einer funktionskongruenten Lösung z.B. in VB.net
oder C# exakt eine Zeile pro Verzweigung. (Wobei man in VB.net sogar
diese Zeile mehr noch wegtricksen könnte).
Also: völlig sinnloser, völlig nutzloser Syntax-Bombast.
Von Leuten, die nix anderes zu tun haben, als sich schwachsinnige
Erweiterungen für die Syntax auszudenken für Leute, die nix anderes zu
tun haben, als das dann zu bejubeln.
Armselig...
Das schlimme an der Sache ist eigentlich: das passiert in allen aktiven
Sprachen. Auch z.B. in VB.net/C#.
Es dient wohl letztlich eigentlich nur dazu, die Sprache "obfuskierbar"
zu machen. Sprich: Es soll nur jemand den Quelltext lesen können, der
mehr Zeit dafür aufwendet, sich die neuesten Syntaxblähungen der Sprache
reinzuziehen, als seine eigentlichen Probleme mit Hilfe der Sprache zu
lösen.
Studtentenulk hätte man das früher genannt...
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:> Spart im Vergleich zu einer funktionskongruenten Lösung z.B. in VB.net> oder C# exakt eine Zeile pro Verzweigung.
Es wird dich jetzt schockieren, aber es geht überhaupt nicht darum
Zeilen zu sparen.
Wenn ich ein .exe ausführe ist es egal mit welcher C/C++ Version
geschrieben wurde, bei Python ist für solche Änderungen eine neue
Runtime nötig. Das macht die Änderungen nervig, das dann ständig neue
Runtimes installiert werden müssen.
Johannes S. schrieb:> bei Python ist für solche Änderungen eine neue Runtime nötig.
Du vergleichst Äpfel mit Birnen.
Sourcecode mit Binaries.
Aber dir kann geholfen werden, indem du hiermit
https://cx-freeze.readthedocs.io/en/latest/
ein Binary aus deinem Python-Sourcecode generierst.
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.
MaWin schrieb:> Dieter H. schrieb:>> den man fast nie nutzt.>> Ja, dann nutze es halt nicht. Wo ist das Problem?
Das Problem ist, daß nicht jeder als einziger Entwickler an
Kleinprojekten "from scratch" tätig ist. Vielmehr muß man die
Vereinigungsmenge aus allem können, was irgendwann irgendeiner der
Vorgänger mal cool fand.
Das ist übrigens auch bei C++ ein Problem, was in der Industrie oft mit
Subsetting gelöst wird. Dummerweise ist es in jeder Firma ein anderes
Subset.
Nop schrieb:> Vielmehr muß man die> Vereinigungsmenge aus allem können, was irgendwann irgendeiner der> Vorgänger mal cool fand.
Pattern matching ist ein etabliertes Paradigma. Das ist nichts, was
irgendein jugendlicher Programmierer gerade hip findet.
Außerdem habt ihr ein Problem mit euren Prozessen, wenn jeder beliebig
herumfrickeln kann und einfach mal eine neue Pythonversion installieren
darf und die zum neuen Standard erheben darf.
MaWin schrieb:> Egon D. schrieb:>> Funktioniert das so ähnlich wie in Tcl, wo das "Pattern">> in jedem Zweig des "switch" auch ein regulärer Ausdruck>> sein kann?>> Nein. Es funktioniert in etwa so, wie match auch in anderen> modernen Sprachen funktioniert. Zum Beispiel wie in Rust.
Ahhh okay. Also nicht interessant.
Wenn man mir den Nutzen nicht in zwei klaren (nicht selbst-
bezüglichen) Sätzen erklären kann, dann brauche ich es nicht.
Nett. Mit Wildcards ist das sogar noch mächtiger als switch/case in
Matlab.
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.
Du brauchst es nicht.
Egon D. schrieb:> Wenn man mir den Nutzen nicht in zwei klaren (nicht selbst-> bezüglichen) Sätzen erklären kann,
Es wird dich jetzt überraschen, aber die meisten Dinge kann man nicht in
zwei Sätzen erklären.
Lies halt das PEP. Dafür ist es da. Dort steht auch eine kurze
Zusammenfassung des Nutzens. Mit Beispielen.
> dann brauche ich es nicht.
Niemand zwingt dich.
Du verpasst aber etwas.
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. Und auch in den Umfragen von StackOverflow
ist Python seit Jahren der oder zumindest unter den Spitzenreitern...
und wie wir wissen, gibt es dafür sehr gute Gründe. ;-)
Yalu X. schrieb:> 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 :)
Ach komm, Yalu, magst Du den Troll nicht bitte lieber entsorgen, anstatt
ihn noch zu füttern?
>> 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 woher sollte ein VB.NjET-"Profi" so etwas denn wissen? ;-)
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
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.
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.
Michael D. schrieb:> Das Problem sind Projekte mit vielen Entwicklern bei denen jeder ein> anderes exotisches Feature entdeckt hat
Patternmatching als exotisches Feature zu bewerten, sagt einiges über
deinen Wissensstand über den aktuellen Stand der Technik aus.
> und verwendet welches die> anderen nicht kennen und verstehen.
Dann müssen sie es lernen. Nennt sich Weiterbildung.
Außerdem habt ihr ein Problem mit euren Prozessen, wenn jeder
X-beliebige Entwickler einfach mal so ein Update des Python-Interpreters
machen kann.
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.
Sven B. schrieb:> Ja, nur gibt es halt Sprachen (C++), bei denen das quasi nicht mehr> sinnvoll moeglich ist.
Genau so sieht das aus. Und dieser grenzdebile Wahnsinn erfaßt immer
mehr lebendige Programmiersprachen.
c-hater schrieb:> dieser grenzdebile Wahnsinn
Ihr könntet auch mal alle einen Gang zurückschalten und euch dieses neue
Feature (pattern matching) einfach einmal anschauen.
Man kann sicher das eine oder andere Detail daran kritisieren.
Es sind auch nicht alle Punkte so umgesetzt, wie ich mir das gewünscht
hätte.
In Summe ist das Feature aber nützlich, vernünftig und optional.
Sich den Stillstand der Welt zu wünschen, ist jedenfalls nicht
zielführend.
Yalu X. schrieb:> 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.
Das klingt danach, als ob deine Traum-Version von Programmiersprache nur
ein Statement besitzt:
_BESORG ES MIR;_
Und alles weitere soll der zugehörige Compiler gefälligst riechen.
Wo bleibt dabei eigentlich das Ziel einer Mikrocontroller-Verwendung wie
vor allem irgend ein anwendbares (und verkaufsfähiges) Gerät?
W.S.
W.S. schrieb:> Das klingt danach, als ob deine Traum-Version von Programmiersprache nur> ein Statement besitzt:> _BESORG ES MIR;_
sagt der Magic Number Spezi jemanden der richtig gut programmieren kann.
Und mit MicroPython ist Python schon lange in die µC Welt eingezogen und
erfreut sich wachsender Beliebtheit.
Das ist ja ganz wunderbar. Keine unübersichtlichen if/else-Treppen mehr.
Das fehlende switch-Statement war in meiner persönlichen Hitliste der
Python-Nachteile ganz oben mit dabei.
Yalu X. schrieb:> Damit kann ab sofort Python-Code noch eleganter, übersichtlicher und> weniger fehlerträchtig geschrieben werden.
Ja klar,
case _:
statt default, otherwise, else. Ansonsten aber ganz nett.
Und dann haben wir noch einen Psychopathen aus dem
Programmiererkindergarten hier im thread, der leider seinen Namen noch
nicht schreiben kann und daher MaWin ins Namensfeld schreibt.
MaWin schrieb:> Und dann haben wir noch einen Psychopathen aus dem> Programmiererkindergarten hier im thread, der leider seinen Namen noch> nicht schreiben kann und daher MaWin ins Namensfeld schreibt.
MaWin ist kein Name - MaWin ist eine Sozialprognose.
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.
Yalu X. schrieb:> Das hat schon seinen Sinn
Nein.
Das ist ähnlich unsinnig, wie bei Sprachen kein leeres Statement zu
erlauben wir C es tut
if(i==1) ;
sondern zu sagen man könne ja etwas das nichts tut als Lückenfüller
verwenden
if(i==1) i=i;
Quasi Faulheit der Sprachdesigner es richtig zu machen.
Uups, Phython is ja so doof:
if i==1:
print("nach if kein bedingtes statement")
IndentationError.
if i==1:
i=i
print("so gehts")
Und die Forensoftware ist auch doof, man sieht wie klug die Entscheidung
der C Sprachentwickler war, sich nicht auf Newline und Whitesoace zu
stützen, die ahnten schon dass eines Tages Forensoftware dann das
Programm zerhackt.
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:
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:
Rolf M. schrieb:> Nein, die Lösung, die Python dafür hat, sieht so aus:
Fake-MaWin, der alle anderen Leute gerne als Psychopathen bezeichnet,
hat leider keinerlei Ahnung von Softwareentwicklung.
Rolf M. schrieb:> die Lösung, die Python dafür hat,
Lies den ganzen thread.
Es geht nicht darum, dass Python ein pass-Statement hat, um in Fällen,
wo syntaktisch ein Statement gefordert wird, man was hinschreiben kann
was nichts tut.
Sondern es ging darum, dass es eben KEIN Schlüsselwort für den
default/otherwise/else Fall des match case hat, sondern da mit
egal-Konstruktionen in der Art von i=i zu arbeiten ist..
UEneegante unvernünftig, unübersichtlich.
Man könnte fragen : Warum nicht ein eigenes Schlüsselwort wie bei pass.
n
> von MaWin (Gast)18.10.2021 20:49
Wir wissen bereits, dass der Psychopath, der seinen Namen nicht kennt
und stattdessen MaWin ins Namensfeld schreibt, ein Programmierhansel
ist. Programmierhansel sind halt meistens irgendwie psychisch gestört.
MaWin schrieb:> Sondern es ging darum, dass es eben KEIN Schlüsselwort für den> default/otherwise/else Fall des match case hat, sondern da mit> egal-Konstruktionen in der Art von i=i zu arbeiten ist..
Du hast match halt nicht verstanden.
Lies das PEP und bilde dich, Fake-MaWin
Thread beobachten
Seitenaufteilung abschalten