Diskussion:Python (Programmiersprache)
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.Archiv |
/Archiv/1 · /Archiv/2 |
Wie wird ein Archiv angelegt? |
Funktionale Programmierung
BearbeitenMeiner Meinung nach könnte der Abschnitt zur funktionalen Programmierung einen Hinweis auf functools vertragen. Hingegen verstehe ich nicht, warum als erstes auf Coconut hingewiesen wird, da es eine komplett andere Programmiersprache ist. (nicht signierter Beitrag von 2001:9E8:6C65:B400:177B:F79D:C488:2501 (Diskussion) 19:03, 8. Mär. 2022 (CET))
match - Verzweigung
BearbeitenAnders als im Artikeltext beschrieben, gibt es in Python ein Semi-Äquivalent von switch
. Dieses heißt jedoch match
und funktioniert etwas anders. --FF-11(Disk.|Bewertung|Beiträge)•Jungwikipedianer 18:27, 22. Jun. 2022 (CEST)
- Nun ja, man muss das etwas differenziert betrachten; „etwas anders“ ist eine Untertreibung. Konstrukte wie
switch
in C/C++ odercase
in der Bourne-Shell sind im Grunde genommen nichts weiter als ein Ersatz fürif
…else
-Kaskaden, d.h.if
-Abfragen mit mehreren Alternativen (Mehrfachverzweigung). Dagegen dient dasmatch
…case
-Konstrukt, das kürzlich mit Python 3.10 eingeführt wurde, für „structured pattern matching“ (ich bin nicht sicher, ob es einen etablierten deutschen Fachbegriff dafür gibt), wie es vor allem in funktionalen Sprachen verbreitet ist, z. B. Haskell, Erlang und Scala, wobei das Binden von Werten aus dem Pattern auf lokale Variablen ein zentraler Aspekt ist. Man kann dies auch für einfache (aber nicht alle!) Anwendungsfälle vonif
…else
-Kaskaden „missbrauchen“, aber es gibt da ein paar Stolpersteine. Der folgende Schnipsel hat z B. nicht das Ergebnis, das man vielleicht erwarten würde: RED = 1 GREEN = 2 BLUE = 3 ... switch mycolor: match RED: print ("Farbe ist rot") ...
- Dieser Code ist fehlerhaft (also bitte nicht als Beispiel verwenden!) und gibt immer den Text „Farbe ist rot“ aus, egal welchen Wert die Variable mycolor hat, weil das Pattern-Matching eben anders funktioniert als ein
if
-Ausdruck. Aus diesem Grund ist die Aussage durchaus weiterhin korrekt, dass Python kein gleichwertiges Äquivalent vonswitch
(C/C++),case
(Shell) o. ä. hat. Nichtsdestotrotz ist das neue Pattern-Matching in Python ein extrem mächtiges Werkzeug, das in dem Artikel einen eigenen Abschnitt verdient hat. Wer neugierig ist, dem empfehle ich die Lektüre des Tutorials in PEP 636. --Winof (Diskussion) 12:43, 23. Jun. 2022 (CEST)- Es geht mir um genau zu sein um den Abschnitt #Syntax vor der ersten Unterüberschrift. Dort wird beschrieben, dass Python zur besseren Lesbarkeit
switch
nicht böte. Mitmatch
scheint das aber nicht mehr so wirklich zutreffend zu sein (trotz der großen Unterschiede). --FF-11(Disk.|Bewertung|Beiträge)•Jungwikipedianer 18:15, 23. Jun. 2022 (CEST)- Es trifft durchaus immer noch zu; ältere PEPs für die Einführung eines „klassischen“
switch
-Statements wurden u. a. mit dieser Begründung abgelehnt, und daran hat sich nichts geändert. Es wurde ja kein solches Statement eingeführt. Aber ich gebe dir insofern recht, dass die Formulierung zu Missverständnissen und Verwechslungen führen kann. Daher tendiere ich dazu, den Satz komplett zu entfernen, denn so wichtig ist es nun auch wieder nicht (zum Vergleich: im Artikel C (Programmiersprache) wird dasswitch
/case
-Statement überhaupt nicht erläutert). Stattdessen sollte ein eigener Abschnitt zum structured pattern matching hinzugefügt werden; evtl. denke ich mir dazu etwas aus, wenn ich ein bisschen Zeit habe. --Winof (Diskussion) 09:24, 24. Jun. 2022 (CEST)
- Es trifft durchaus immer noch zu; ältere PEPs für die Einführung eines „klassischen“
- Es geht mir um genau zu sein um den Abschnitt #Syntax vor der ersten Unterüberschrift. Dort wird beschrieben, dass Python zur besseren Lesbarkeit
- Ich habe jetzt den fraglichen Satz entfernt, wie ich oben schrieb. Aber nach genauerem Hinschauen fällt auf, dass eigentlich der ganze Abschnitt überarbeitungsbedürftig ist. Dort steht, Python habe wenig „syntaktische Konstruktionen“ (sehr schwammig – was soll das genau sein?), und führt dann lediglich
for
,while
undif
auf. Das stimmt so nicht bzw. es erweckt einen falschen Eindruck; man müsste mindestens auchtry
…except
undwith
erwähnen, sowie das neuematch
…case
. Natürlich sind auch Funktions- und Klassen-Definitionen „syntaktische Konstruktionen“, und dann gibt es noch Dinge wieasync
, Coroutinen und diverses andere. Vielleicht hat ja jemand Muße, den Abschnitt zu überarbeiten. Ich kann es auch versuchen, aber das wird vermutlich etwas dauern, da ich gerade reichlich andere Dinge zu tun habe. --Winof (Diskussion) 10:12, 24. Jun. 2022 (CEST)
Darstellung im Bild Datentypen und Strukturen ist nicht korrekt
BearbeitenDer Fakt, dass Bool ein integraler Typ ist, aber parallel zu int existiert ist leider falsch und führt in speziellen Fällen auch zu unerwarteten Problemen. Tatsächlich ist bool eine Ableitung von int (leicht zu prüfen mit issubclass(bool, int) bzw. so steht es auch auf der verwiesenen Seite: 'The Boolean type is a subtype of the integer type'). Für ein Grundverständnis kann die Darstellung sicher so bleiben, dem Anspruch auf exakte Darstellung genügt das aber nicht. --Matthias Kupfer 14:56, 30. Jul. 2023 (CEST)
Wikipedia - ein allgemeines Nachschlagewerk?
BearbeitenWiki ist einmal angetreten, das Buch als Lexikon abzulösen. Ich habe mehrere Programmiersprachen gelernt, ua C++, und habe dennoch Mühe, das Kauderwelsch zu verstehen. Mir scheint, das ist eine Spielwiese für Informatiker. --2003:F7:AF31:7800:4DBA:BCA7:846D:88C9 23:27, 13. Feb. 2024 (CET)
- WP:Sei mutig und verbessere den Artikel. --Sebastian.Dietrich ✉ 08:58, 14. Feb. 2024 (CET)
"Für Programmierneulinge wird der Zwang zu lesbarem Stil aber als Vorteil gesehen."
BearbeitenWas soll mir diese sinnentstellende Aussage bitte sagen? Wen interessiert es, was Programmier"neulinge" denken; ab wann sind Programmier"neulinge" keine Programmier"neulinge" mehr und haben die dann eine andere Meinung, die auch wieder keinen interessiert?
Wie begründet denn ein Programmier"neuling" den angeblichen "Vorteil" und wen juckt das? --79.204.211.7 00:39, 18. Mai 2024 (CEST)
- Warum sollte ein Neuling das begründen? Wenn er Python nutzt/nutzen muss, wird ihm das so vorgeschrieben.
- Ernsthaft, diese Aussage muss als TF betrachtet werden, solange es keine (reputable) Quelle gibt, die sich damit beschäftigt. Vielleich hat ja Landin selbst etwas dazu gesagt? Interessanterweise erwähnt en:Offside-Rule einen Scala-Profi, der den Produktivitätsgewinn herausstreicht. Kannst gerne mutig sein :-) --Burkhard (Diskussion) 16:56, 18. Mai 2024 (CEST)
- Hab die Programmierneulinge mal herausgenommen, und ersetzt mit Guido's Meinung dazu. --Heronils (Diskussion) 16:04, 21. Mai 2024 (CEST)
- Danke, schon mal besser. Von überlangen Code-Zeilen lese ich in der verlinkten Quelle aber nichts (und kann das als Argument auch nicht wirklich nachvollziehen) - oder habe ich etwas übersehen? Die Formulierung "beseitigt ... Irrtümer des Programmierers" ist sprachlich etwas seltsam - natürlich gibt es auch mit Einrückungen immer noch genügend andere Möglichkeiten, sich zu verhaun :-(. Gemeint ist doch wohl eher, dass optisch leichter zu erkennen ist, welche Statements zu einem Block gehören? Just BTW: erfahrene Programmiererinnen wissen auch so, wie man sich nicht in den eigenen Fuß schiesst - aber das ist eine andere Diskussion. Gruß, --Burkhard (Diskussion) 17:09, 21. Mai 2024 (CEST)
- Ja, das mit den überlangen Codezeilen habe ich aus dem letzten Absatz falsch herausgelesen. Der meinte ja, dass der Code vertikal wächst, nicht horizontal. Habe ich korrigiert. Das C Codebeispiel in der Quelle ist auch diskussionswürdig, dieser Fehler entsteht ja nur, weil C die Verwendung von Klammern nicht immer erzwingt, was ich für einen Fehler halte und selbst niemals machen würde. Aber das im Lemma zu erwähnen wäre ja Theoriefindung. Ich bin im übrigen auch skeptisch bezüglich der Python Einrückung, wegen Argumenten wie diesen. Auch macht es Lambdas weniger nützlich als in anderen Sprachen. Aber wie schon gesagt, das wäre Theoriefindung. --Heronils (Diskussion) 02:04, 22. Mai 2024 (CEST)
- Danke, schon mal besser. Von überlangen Code-Zeilen lese ich in der verlinkten Quelle aber nichts (und kann das als Argument auch nicht wirklich nachvollziehen) - oder habe ich etwas übersehen? Die Formulierung "beseitigt ... Irrtümer des Programmierers" ist sprachlich etwas seltsam - natürlich gibt es auch mit Einrückungen immer noch genügend andere Möglichkeiten, sich zu verhaun :-(. Gemeint ist doch wohl eher, dass optisch leichter zu erkennen ist, welche Statements zu einem Block gehören? Just BTW: erfahrene Programmiererinnen wissen auch so, wie man sich nicht in den eigenen Fuß schiesst - aber das ist eine andere Diskussion. Gruß, --Burkhard (Diskussion) 17:09, 21. Mai 2024 (CEST)
- Hab die Programmierneulinge mal herausgenommen, und ersetzt mit Guido's Meinung dazu. --Heronils (Diskussion) 16:04, 21. Mai 2024 (CEST)