„Diskussion:Python (Programmiersprache)“ – Versionsunterschied
Inhalt gelöscht Inhalt hinzugefügt
K Bot: Signaturnachtrag für Beitrag von 188.98.217.58 | K →"Für Programmierneulinge wird der Zwang zu lesbarem Stil aber als Vorteil gesehen.": neutraler formuliert. | ||
| (46 dazwischenliegende Versionen von 20 Benutzern werden nicht angezeigt) | |||
| Zeile 7: | Zeile 7: | ||
{{Autoarchiv|Alter=180|Ziel='Diskussion:Python (Programmiersprache)/Archiv/2'|Mindestbeiträge=2|Mindestabschnitte=5|Frequenz=monatlich}} | {{Autoarchiv|Alter=180|Ziel='Diskussion:Python (Programmiersprache)/Archiv/2'|Mindestbeiträge=2|Mindestabschnitte=5|Frequenz=monatlich}} | ||
== Funktionale Programmierung == | |||
== Skriptsprache? == | |||
Meiner Meinung nach könnte der Abschnitt zur funktionalen Programmierung einen Hinweis auf [https://docs.python.org/3/library/functools.html functools] vertragen. | |||
Ich denke, es wäre besser Python eher als Skriptsprache zu klassifizieren. Schließlich wird Python mehr interpretiert. | |||
Hingegen verstehe ich nicht, warum als erstes auf Coconut hingewiesen wird, da es eine komplett andere Programmiersprache ist. {{unsigniert|2001:9E8:6C65:B400:177B:F79D:C488:2501|19:03, 8. Mär. 2022 (CET)}} | |||
Siehe hierzu auch [[:Kategorie:Skriptsprache]]. --<small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/178.4.180.215|178.4.180.215]] ([[Benutzer Diskussion:178.4.180.215|Diskussion]])<nowiki/> 18:07, 6. Feb. 2018 (CET))</small> | |||
:Nein, Python-Quellcode wird zunächst zu Bytecode compiliert, der dann von einer Python-VM ausgeführt wird – zumindest bei der offiziellen Referenz-Implementation („CPython“). Dies ist ganz ähnlich wie bei Java, wo der Quellcode ebenfalls zu Bytecode compiliert wird (sogenannte Klassendateien), die dann von einer Java-VM ausgeführt werden. Der einzige Unterschied ist, dass bei Python beide Schritte normalerweise gemeinsam ausgeführt werden und daher aus Benutzersicht nicht getrennt wahrgenommen werden. Man sieht es aber an den <code>*.pyc</code>-Dateien, in denen beim Compilieren von Modulen der Bytecode zwischengespeichert wird. Selbst der interaktive Prompt von Python ist kein Interpreter im engeren Sinn, auch wenn er zuweilen so bezeichnet wird: Auch hier wird jede Eingabe zunächst zu Bytecode compiliert. | |||
:Übrigens gibt es auch weitere (Dritt-)Implementationen der Sprache Python. Beispielsweise gibt es Compiler, die Java-Bytecode erzeugen, so dass Python-Programme unter einer Java-VM ausgeführt werden können. Desweiteren gibt es auch Compiler, die „nativen“ Code erzeugen, der direkt auf der jeweiligen Plattform ausgeführt werden kann, ohne VM. --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 14:34, 7. Feb. 2018 (CET) | |||
== match - Verzweigung == | |||
::Ähm, nö. Python-Bytecode wird interpretiert, wie schon vor Jahrzehnten das alte Basic. | |||
::Im Gegensatz dazu wird Java-Bytecode von heutigen JVMs tatsächlich JIT-''kompiliert''. Dass eine Java-VM ein Bytecode-''Interpreter'' war, ist afaik seit Java 1.1 Geschichte. | |||
::Von den Python-to-Maschinencode-''Compilern'' ist ''keiner'' vollständig Python-Referenz-kompatibel. | |||
::Der einzige verbreitete und wirklich schnelle, Cython, wird nur dann schnell, wenn man sich '''weit''' von CPython entfernt, z.B. auf dynamische Typisierung verzichtet, auf Objektorientierung verzichtet, und das Speichermanagement selbst macht (à la [[C (Programmiersprache)|C]]-<code>malloc(...)</code> und -<code>free(...)</code>). Und sonst noch ein paar kleinere Abweichungen vom Referenz-Python. | |||
::--[[Benutzer:Arilou|arilou]] ([[Benutzer Diskussion:Arilou|Diskussion]]) 15:38, 3. Dez. 2018 (CET) | |||
Anders als im Artikeltext beschrieben, gibt es in Python ein Semi-Äquivalent von <code>switch</code>. Dieses heißt jedoch <code>match</code> und funktioniert etwas anders. --[[Benutzer:FF-11|FF-11]]<small>([[BD:FF-11|Disk.]]|[[User:FF-11/Bewertung|Bewertung]]|[[Spezial:Beiträge/FF-11|Beiträge]])•''[[WP:J|Jungwikipedianer]]''</small> 18:27, 22. Jun. 2022 (CEST) | |||
:::Worauf genau bezieht sich Dein „nö“? Nichts von dem, was Du geschrieben hast, widerspricht dem, was ich geschrieben habe. | |||
: Nun ja, man muss das etwas differenziert betrachten; „etwas anders“ ist eine Untertreibung. Konstrukte wie <code>switch</code> in C/C++ oder <code>case</code> in der Bourne-Shell sind im Grunde genommen nichts weiter als ein Ersatz für <code>if</code>…<code>else</code>-Kaskaden, d.h. <code>if</code>-Abfragen mit mehreren Alternativen (Mehrfachverzweigung). Dagegen dient das <code>match</code>…<code>case</code>-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 (Programmiersprache)|Haskell]], [[Erlang (Programmiersprache)|Erlang]] und [[Scala (Programmiersprache)|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 von <code>if</code>…<code>else</code>-Kaskaden „missbrauchen“, aber es gibt da ein paar Stolpersteine. Der folgende Schnipsel hat z B. '''nicht''' das Ergebnis, das man vielleicht erwarten würde: | |||
:::Nochmal: Python-Quellcode wird zunächst zu Bytecode compiliert. Ob zur Ausführung dieser Bytecode dann interpretiert oder von einem Chip in Hardware ausgeführt wird (oder sonstwas), ist ein Implementierungsdetail und hat ''nichts'' damit zu tun, ob die ''Sprache'' Python eine Skriptsprache ist oder nicht. Davon abgesehen würde ich den Begriff Skriptsprache eher nach der Art der Verwendung klassifizierenn, nicht, ob es interpretiert wird (sonst wäre BASIC auch eine Skriptsprache). Selbstverständlich ''kann'' man Python als Skriptsprache verwenden (und das steht ja auch bereits in der Einleitung des Artikels), aber sie generell auf diese Verwendung einzuschränken, wäre irreführend. --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 14:59, 16. Jan. 2019 (CET) | |||
: <syntaxhighlight lang="python"> | |||
RED = 1 | |||
GREEN = 2 | |||
BLUE = 3 | |||
... | |||
::::"''Nichts von dem, was Du geschrieben hast, widerspricht dem, was ich geschrieben habe.''" ~ Dann also en detail: | |||
::::#"''Dies ist ganz ähnlich wie bei Java [...] Der einzige Unterschied ist, dass bei Python beide Schritte normalerweise gemeinsam ausgeführt werden und daher aus Benutzersicht nicht getrennt wahrgenommen werden.''" ~ ~ jaja, 'einziger Unterschied'... Bei Java betreibt die JVM seit Ewigkeiten JIT-Kompilierung, bei Python macht das die Referenzimplementierung heute noch nicht. Damit ist Java (bzgl. der Ausführungsgeschw.) nahe an nativem, kompiliertem Code, und Python *räusper* ''weit'' davon entfernt. | |||
::::#"''Selbst der interaktive Prompt von Python ist kein Interpreter im engeren Sinn, auch wenn er zuweilen so bezeichnet wird: Auch hier wird jede Eingabe zunächst zu Bytecode compiliert.''" - das machten schon die Basic-''Interpreter'' der 1970er. Die nennt man ''trotzdem'' "Interpreter" - sorry, aber so isses. | |||
::::#"''Desweiteren gibt es auch Compiler, die „nativen“ Code erzeugen, der direkt auf der jeweiligen Plattform ausgeführt werden kann, ohne VM.''" - und nochmal 'nö'. Der Großteil dieser Compiler (a) bringt entweder kaum etwas (an Geschwindigkeit), oder (b.1) sie unterstützen Python nur (deutlich) unvollkommen oder (b.2) man muss erheblich von Python abweichen (z.B. Richtung C), um nennenswerte Verbesserungen (der Geschw.keit) zu erhalten. Bei den (b)-Fällen ist dann schon zweifelhaft, ob man sowas noch "''Python''"-Compiler nennen soll. | |||
::::Worin ich dir jedoch voll zustimme: Ob etwas eher "Skriptsprache" oder "für große Programme geeignete Voll-Sprache" ist, sollte nach der Art der Verwendung klassifiziert werden ~ sowie nach den Sprach-Fähigkeiten (ob es Objektorientierung gibt, ob ein modularer Programmaufbau möglich ist, ...). | |||
::::--[[Benutzer:Arilou|arilou]] ([[Benutzer Diskussion:Arilou|Diskussion]]) 16:46, 16. Jan. 2019 (CET) | |||
switch mycolor: | |||
::::: Meine Aussagen bezogen sich auf den Schritt, vom Quelltext der ''Sprache'' Bytecode zu erzeugen. Diesen Schritt nennt man Compilierung. Und diesen Schritt gibt es bei Python ''und'' Java (und bei diversen anderen Sprachen bzw. üblichen Implementationen). Was danach mit dem Bytecode passiert, steht auf einem anderen Blatt, und dort unterscheiden sich Python und Java selbstverständlich, wie Du ganz richtig geschrieben hast. | |||
match RED: | |||
::::: Übrigens, die meisten mir bekannten BASIC-Implementationen der 70er (Wang, Commodore, CP/M) haben ''keinen'' Bytecode erzeugt, sondern wurden direkt interpretiert. Bei einigen Implementationen war es lediglich üblich, die reservierten Wörter in Token-Codes zu übersetzen, aber das hat nichts mit Bytecode zu tun. Der einzige BASIC-Compiler aus der Zeit, den ich kenne, ist BASCOM, aber der hat auch schon direkt Maschinencode erzeugt, keinen Bytecode. Gut, das mag jetzt Haarspalterei sein; Bytecode ist ja im Grunde auch nichts weiter als eine Art Maschinencode. Aber das wird jetzt allmählich off-topic … --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 19:19, 16. Jan. 2019 (CET) | |||
print ("Farbe ist rot") | |||
... | |||
</syntaxhighlight> | |||
: 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 <code>if</code>-Ausdruck. Aus diesem Grund ist die Aussage durchaus weiterhin korrekt, dass Python kein gleichwertiges Äquivalent von <code>switch</code> (C/C++), <code>case</code> (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 [https://peps.python.org/pep-0636/ Tutorials in PEP 636]. --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 12:43, 23. Jun. 2022 (CEST) | |||
::Es geht mir um genau zu sein um den Abschnitt [[Python (Programmiersprache)#Syntax|#Syntax]] vor der ersten Unterüberschrift. Dort wird beschrieben, dass Python ''zur besseren Lesbarkeit'' <code>switch</code> nicht böte. Mit <code>match</code> scheint das aber nicht mehr so wirklich zutreffend zu sein (trotz der großen Unterschiede). --[[Benutzer:FF-11|FF-11]]<small>([[BD:FF-11|Disk.]]|[[User:FF-11/Bewertung|Bewertung]]|[[Spezial:Beiträge/FF-11|Beiträge]])•''[[WP:J|Jungwikipedianer]]''</small> 18:15, 23. Jun. 2022 (CEST) | |||
:::Es trifft durchaus immer noch zu; ältere PEPs für die Einführung eines „klassischen“ <code>switch</code>-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 das <code>switch</code>/<code>case</code>-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. --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 09:24, 24. Jun. 2022 (CEST) | |||
: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 <code>for</code>, <code>while</code> und <code>if</code> auf. Das stimmt so nicht bzw. es erweckt einen falschen Eindruck; man müsste mindestens auch <code>try</code>…<code>except</code> und <code>with</code> erwähnen, sowie das neue <code>match</code>…<code>case</code>. Natürlich sind auch Funktions- und Klassen-Definitionen „syntaktische Konstruktionen“, und dann gibt es noch Dinge wie <code>async</code>, 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. --[[Benutzer:Winof|Winof]] ([[Benutzer Diskussion:Winof|Diskussion]]) 10:12, 24. Jun. 2022 (CEST) | |||
::::::Wenn ich den Basic-Interpreter als „Virtuelle Maschine für Basic-Tokencode“ betrachte, sehe ich nicht mehr viele Unterschiede zu Python-Bytecode. Auch konnten viele Basic-Interpreter den Tokencode analog zu .pyc als "Kompilat" aus einer Datei ausführen bzw. darin speichern. | |||
::::::Aber da es in diesem Disku-Punkt hier sowieso nur um eine Frage und nicht um eine Artikel-Verbesserung geht, können wir auch darin verbleiben: Wir haben (teilweise) unterschiedliche Sichtweisen/Standpunkte und haben sie dargelegt. Der Leser dieses Disku-Punkts mag sich selbst eine Meinung bilden. | |||
::::::--[[Benutzer:Arilou|arilou]] ([[Benutzer Diskussion:Arilou|Diskussion]]) 09:43, 17. Jan. 2019 (CET) | |||
== Darstellung im Bild Datentypen und Strukturen ist nicht korrekt == | |||
== Kritikabschnitt == | |||
Mal davon ab, dass nicht viele Sprachen einen haben (Perl, erwartbar), von wann ist der eigentlich? Die Quellen führen in's Webarchiv oder auf Zeitungsartikel von sage und schreibe 1999! Los geht's mit einer bloßen Empfindung, deren Anstoß ich nur von hier kenne. Folgt eine Anekdote aus 2.x-Zeiten, die man sich in Kürze eh sparen möchte. Und dann natürlich der GIL: afaik auch so'n Dauerbrenner der 2000er Jahre, seit wann gibt's Multiprocessing in der Standardbibliothek jetzt? Glaube solange ich Python kenne und das ist auch schon ne Weile. Ausführungsgeschwindigkeit: um 2020? Das ist doch peinlich. Wenn man so einen Abschnitt will, dann muss er seinem Ansinnen gerecht werden und dann müsste man das auch mal pflegen. Oder irgendwann eben ''mal'' Konsequenzen ziehen und sowas auch einfach löschen, viell. hat mal wieder jemand Lust? Ich könnt bis dahin gut drauf verzichten und ziemlich das Einzige, was mir dazu einfiele, sich auf die Sprache i.e.S. bezieht, aber wohl auch schwerlich zitieren ließe, wären die mittlerweile vier, bzw. fünf Möglichkeiten formatierter Textausgabe, von wegen "one way to do it" - das ein und im Ggs. zu ich glaube allen jetzigen Punkten wenigstens auch recht einmaliges Merkmal von Python, aber sicher kaum weniger affig als das, was da jetzt steht. -[[Benutzer:Zero Thrust|ZT]] ([[Benutzer Diskussion:Zero Thrust|Diskussion]]) 06:50, 14. Okt. 2019 (CEST) | |||
:Zustimmung in der Sache. Ich bin kein Experte, nur Freizeit-Programmierer (freilich mit gewissen grundsätzlichen Informatik-Kenntnissen), glaube aber auch feststellen zu können, dass der Abschnitt zumindest stark veraltet ist. „Mangelnde Typsicherheit“ z.B. lässt sich durch Einsatz von ''type annotations'' und mypy doch beheben. Auch bei dem (allerdings ubiquitären) Vorwurf mangelnder Ausführungsgeschwindigkeit sollte man zumindest klarmachen, (a) dass das in der Praxis bei vielen Programmen gar keine Rolle (mehr) spielt und (b) das die Ausführungsgeschwindigkeit stark von der eingesetzten Implementierung abhängt. Könnte ein wirklicher Kenner der Materie den Abschnitt grundlegend überarbeiten und aktualisieren? Das wäre super! --[[Benutzer:Aristeas|Aristeas]] ([[Benutzer Diskussion:Aristeas|Diskussion]]) 17:34, 17. Nov. 2019 (CET) | |||
:Die Ausführungsgeschwindigkeit finde ich schon relevant. Python ist in dieser Disziplin auch unter Skriptsprachen nicht besonders optimiert. Dass die Geschwindigkeit für sehr viele Szenarien keine Rolle spielt ist richtig, aber dass man zur Zeit kaum eine langsamere Sprache findet, ist auch erwähnenswert. Natürlich sind Benchmarks nicht immer ganz aussagekräftig. --[[Benutzer:Diaspomod|Diaspomod]] ([[Benutzer Diskussion:Diaspomod|Diskussion]]) 11:30, 18. Nov. 2019 (CET) | |||
Der 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. --[[Benutzer:Matthias Kupfer|Matthias Kupfer]] 14:56, 30. Jul. 2023 (CEST) | |||
Was soll außerdem folgende Behauptung: | |||
:''"Ferner wird die mangelnde statische Typsicherheit der Programmiersprache kritisiert.[49]"'' | |||
In der Quelle [49] lese ich hingegen: | |||
:''Der Mangel an statischer Typsicherheit impliziert auch Risiken, denen jedoch die Vorzüge einer dynamischen Sprache gegenüberstehen. Im Übrigen nötigen die meisten objektorientierten Sprachen, die angeblich ein statisches Typkonzept haben, de facto dauernd dazu, es mittels unsicherer Typumwandlung zu durchbrechen (das gilt auch für Java, siehe [2]), ohne jedoch die schönen Seiten eines dynamischen Konzepts zu bieten.'' | |||
Klingt für mich nicht so, als sei die Quelle neutral und wertfrei wiedergegeben worden. "birgt Risiken" ist keine Kritik, und wenn danach ein Absatz folgt der die Vorzüge anpreist erst recht nicht. Sieht das jemand anders? Ansonsten würde ich das anders formulieren, näher an der Bewertung aus der Quelle. --[[Benutzer:TheRandomIP|TheRandomIP]] ([[Benutzer Diskussion:TheRandomIP|Diskussion]]) 17:09, 1. Sep. 2020 (CEST) | |||
== Wikipedia - ein allgemeines Nachschlagewerk? == | |||
::Zu der Quelle: Dass Typumwandlung unsicher sein soll, ist so nicht richtig. Die Quelle spricht da vermutlich aus Javaperspektive, wo Downcasts eine Ausnahme werfen können, wenn man davor nicht mit dem "instanceof" Operator den Typ geprüft hat. Andere Sprachen wie C# und Kotlin geben da null zurück und erzwingen zum Teil typsichere Typumwandlungen per Design. | |||
:: Die Aussage, dass man de facto andauernd dazu genötigt sei, Downcasts zu machen, ist nicht unbedingt realitätsgetreu und sachlich. --[[Benutzer:Diaspomod|Diaspomod]] ([[Benutzer Diskussion:Diaspomod|Diskussion]]) 21:26, 1. Sep. 2020 (CEST) | |||
Wiki 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. --[[Spezial:Beiträge/2003:F7:AF31:7800:4DBA:BCA7:846D:88C9|2003:F7:AF31:7800:4DBA:BCA7:846D:88C9]] 23:27, 13. Feb. 2024 (CET) | |||
::: Gibt es dann vielleicht andere Quellen, die die mangelnde statische Typsicherheit explizit kritisieren? --[[Benutzer:TheRandomIP|TheRandomIP]] ([[Benutzer Diskussion:TheRandomIP|Diskussion]]) 22:06, 1. Sep. 2020 (CEST) | |||
:[[WP:Sei mutig]] und verbessere den Artikel. --[[Benutzer:Sebastian.Dietrich|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich| ✉ ]] 08:58, 14. Feb. 2024 (CET) | |||
::: ...scheinbar nicht, also habe ich den Satz entfernt. (Ein Umformulieren war nicht nötig, denn die Information, dass Python dynamische Typisierung verwendet, wurde schon an anderer Stelle im Artikel besprochen) --[[Benutzer:TheRandomIP|TheRandomIP]] ([[Benutzer Diskussion:TheRandomIP|Diskussion]]) 14:35, 4. Sep. 2020 (CEST) | |||
== "Für Programmierneulinge wird der Zwang zu lesbarem Stil aber als Vorteil gesehen." == | |||
== wikidata == | |||
Was 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? | |||
Es geht um folgende Zurücksetzung von {{Ping|Xqt}}: https://de.wikipedia.org/w/index.php?title=Python_(Programmiersprache)&oldid=prev&diff=200334618&diffmode=source | |||
also darum, dass in der Infobox Erscheinungsdatum, Designer, Entwickler, Aktuelle Version, Aktuelle Version Freigabedatum, Beeinflusst Von, Lizenz und Website nicht aus wikidata kommen sollten, da "Wikidata ist fehlerhaft, siehe auch diesbezügliches MB". | |||
Zu den einzelnen Punkten: | |||
* Erscheinungsdatum ist in wikidata korrekter, da mit Tag, Monat und Beleg | |||
* Designer ist in wikidata ident zum Artikel inkl. Beleg | |||
* Entwickler ist in wikidata korrekter, da Guido van Rossum inkl. Beleg auch erwähnt wird, ident zum Artikel, der ihn unter "Entwicklungsgeschichte" als Entwickler nennt | |||
* Aktuelle Version war in wikidata nicht korrekt (2er Releasezweig hatte preferred rank) - wurde geändert und ist somit jetzt ident | |||
* Aktuelle Version Freigabedatum - siehe oben | |||
* Beeinflusst Von ist in wikidata korrekter, da belegt | |||
* Lizenz und Website ist ident | |||
d.h. Wikidata scheint weniger fehlerhaft zu sein als Wikipedia - außerdem können dort auch von jedermann Fehler behoben werden (d.h. man muss Fehler nicht in der Wikipedia ausbessern) | |||
Wie begründet denn ein Programmier"neuling" den angeblichen "Vorteil" und wen juckt das? --[[Spezial:Beiträge/79.204.211.7|79.204.211.7]] 00:39, 18. Mai 2024 (CEST) | |||
Mit Meinungsbild war vermutlich dieses gemeint: https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Nutzung_von_Daten_aus_Wikidata_im_ANR aus 2015 | |||
:Warum sollte ein Neuling das begründen? Wenn er Python nutzt/nutzen muss, wird ihm das so vorgeschrieben. | |||
Der hier betroffene Punkt "Das Entfernen von Daten aus der deWP ... ist bis auf Weiteres unzulässig." wurde damals abgelehnt. | |||
: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 (Programmiersprache)|Scala]]-Profi, der den Produktivitätsgewinn herausstreicht. Kannst gerne mutig sein :-) --[[Benutzer:Drahkrub|Burkhard]] ([[Benutzer Diskussion:Drahkrub|Diskussion]]) 16:56, 18. Mai 2024 (CEST) | |||
::Hab die Programmierneulinge mal herausgenommen, und ersetzt mit [https://python-experiment.readthedocs.io/en/latest/faq/design.html#why-does-python-use-indentation-for-grouping-of-statements Guido's Meinung dazu]. --[[Benutzer:Heronils|Heronils]] ([[Benutzer Diskussion:Heronils|Diskussion]]) 16:04, 21. Mai 2024 (CEST) | |||
Fazit: Die Änderungen an der Infobox damit wikidate Infos dargestellt werden war sowohl inhaltlich sinnvoll (da der Artikel dadurch belegter und korrekter wird), als auch dem Meinungsbild entsprechend. | |||
:::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ß, --[[Benutzer:Drahkrub|Burkhard]] ([[Benutzer Diskussion:Drahkrub|Diskussion]]) 17:09, 21. Mai 2024 (CEST) | |||
--[[Benutzer:Sebastian.Dietrich|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich|<big>✉</big>]] 00:43, 27. Mai 2020 (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 [https://www.linkedin.com/pulse/why-python-indentation-sucks-what-can-done-spoiler-alert-mayank-verma diesen]. Auch macht es Lambdas weniger nützlich als in anderen Sprachen. Aber wie schon gesagt, das wäre Theoriefindung. --[[Benutzer:Heronils|Heronils]] ([[Benutzer Diskussion:Heronils|Diskussion]]) 02:04, 22. Mai 2024 (CEST) | |||
: Also korrekt war da gar nichts: Über die Wikidata-Einbindung wurde nämlich das 2.7.18er-Release eingeblendet. Das ist lediglich ein 20. April veröffentlichter Hotfix einer Entwicklungslinie, die seit dem 1. Januar eingestellt ist. Die aktuelle Version ist 3.8.2. Mir ist nicht transparent, welche der in WD gesammelten Versionen-Eigenschaften hier eingeblendet wird, 2.7 ist jdenfalls die falsche. WD arbeitet seit Mitte Januar ohnehin nicht zuverlässig, zumindest aus API-Sicht; da gehen auch schon mal Daten verloren. [[BD:xqt|<small>@</small>]][[Benutzer:xqt|xqt]] 08:00, 27. Mai 2020 (CEST) | |||
:: Danke für [https://www.wikidata.org/w/index.php?title=Q28865&type=revision&diff=1190985125&oldid=1190139850 diese Änderung]. Aber wie kann [https://www.wikidata.org/w/index.php?title=Q28865&oldid=1117854969 dieser Unsinn] verhindert werden, wo es haufenweise Einträge mit bevorzugtem Rang gibt? [[BD:xqt|<small>@</small>]][[Benutzer:xqt|xqt]] 08:19, 27. Mai 2020 (CEST) | |||
::: Ich bin kein Wikidata Spezialist - das mit dem Preferred Rank weiß ich selbst erst seit ein paar Monaten, weil die aktuelle Version bei einer Software partout nicht die letzte sein wollte. Ich vermute es sollte normalerweise so sein: keine Version bekommt einen preferred rank --> die letzte wird genommen. Den preferred Rank braucht man nur, wenn die (zeitlich) letzte Version nicht die letzte ist - das passiert aber nur wenn auch alte Versionen weiterentwickelt/gewartet werden. Das passiert zwar oft, aber in Wikidata kommen diese Versionen dann eh selten rein (niemand macht sich die Mühe Updates an alten Versionen zu aktualisieren). --[[Benutzer:Sebastian.Dietrich|Sebastian.Dietrich]] [[Benutzer Diskussion:Sebastian.Dietrich|<big>✉</big>]] 20:11, 29. Mai 2020 (CEST) | |||
== .NET fehlt == | |||
Warum wurde die Änderung rückgängig gemacht, die neben Java auch .NET nennt, wenn es darum geht, dass Zeichenketten unveränderlich gespeichert werden? Die Änderung war korrekt und sachlich richtig. Hast du eine persönliche Präferenz? | |||
--[[Benutzer:My2Cents|My2Cents]] ([[Benutzer Diskussion:My2Cents|Diskussion]]) 14:30, 30. Jun. 2020 (CEST) | |||
== anspruch und wirklichkeit == | |||
"Sie hat den Anspruch, einen gut lesbaren, knappen Programmierstil zu fördern." | |||
python fördert nicht, python bestraft. ein falsches tab oder ein (wenn auch nur versehentlich) gelöschtes oder hinzugefügtes leerzeichen, | |||
und der scheiß fliegt dir um die ohren. was die formatierung angeht, ist python ca. 3mal so bösartig wie fortran. {{unsigniert|188.98.209.101|00:53, 16. Okt. 2020 (CEST)}} | |||
:Unter anderem ist Python auch case-sensitive, was dir sicher auch Probleme bereiten dürfte. Und die Schreibweise „3mal“ zeigt, dass du auch außerhalb von Python Schwierigkeiten mit Leerzeichen hast …<br>Wie auch immer: Die Artikeldiskussion dient der Verbesserung des Artikels, nicht der Darstellung der eigenen Meinung zum Thema. Wenn du enzyklopädietaugliche Quellen beibringst, die diesen von dir zitierten Anspruch von Python als nicht eingelöst beschreiben, kann das natürlich ebenfalls in den Artikel.<br><span style="font-family:serif;font-variant:small-caps;white-space:nowrap"><span style="text-shadow:grey 0.1em 0.1em 0.3em">[[User:Troubled asset|Troubled @sset]]</span> <sup>[[de:BD:Troubled asset|[ Talk ]]]</sup></span> 07:02, 16. Okt. 2020 (CEST) | |||
:: Wie bei allem der Unterschied zwischen Theorie und Praxis. Enzyklopädietaugliche Quellen wollen doch Python promoten. Keiner schreibt ein Fachbuch «Warum Python Scheisse ist». Er disqualifiziert sich dann selber in der Community. Das Python wie viele andere Programmiersprachen schlicht nicht berücksichtigt ist, das Menschen Programme schreiben, und die vertippen sich ist nun mal eine Tatsache. Das Menschen Variablen verwechseln auch. Ein System welches nicht so viel wie möglich Fehler bei der Auslieferung erkennt ist einfach Schrott «Python is a dynamically typed language. This means that the Python interpreter does type checking only as code runs, and that the type of a variable is allowed to change over its lifetime.[[https://realpython.com/python-type-checking/»]] «Static type checks are performed without running the program. In most statically typed languages, for instance C and Java, this is done as your program is compiled.». Man braucht jetzt wirklich kein Experte zu sein um Folgendes festzustellen: Man schreibt an einem grossen Programm. Es verarbeitet Datensätze zu Rechnungen. In einer Funktion verwechsele man Variable i mit I. Der Fehler wird nicht sofort erkannt. Nein, er wird Wochen später erkannt, nachdem Hunderte fehlerhafter Rechnungen an Kunden verschickt wurden. Aber so etwas steht nicht in Enzyklopädietaugliche Quellen. Keiner gibt sich die Blösse das er ein Looser ist der i mit I verwechselt. Wie bei allen Skriptsprachen sollte eine Warnung in den Artikel. «Bitte beachten: Python schadet ihrer Gesundheit. Es wird sie in den Wahnsinn bei grösseren Projekten treiben!» Python ist nicht Typ Sicher und deswegen abzulehnen. Der Testaufwand in grösseren Projekten ist einfach zu gross! Guten Morgen. [[Benutzer:Valanagut|ไม่เป็นไร (Valanagut)]] ([[Benutzer Diskussion:Valanagut|Diskussion]]) 09:29, 16. Okt. 2020 (CEST) | |||
::: Keiner schreibt ein Fachbuch «Warum Python Scheisse ist». | |||
::: Polemisch. Schon mal "Why x is bad" in eine Suchmaschine eingegeben? [[Spezial:Beiträge/185.69.244.136|185.69.244.136]] 13:56, 16. Okt. 2020 (CEST) -- | |||
:::: ich möchte noch anmerken, daß der von mir zitierte satz zunächst mal marketinggeschwafel ist. was die entwickler sich gewünscht haben, ist irrelevant. ich sehe auch deswegen keinen grund, warum ich (oder irgendjemand anderes) die beweislast tragen soll, das zu widerlegen. wer eine behauptung aufstellt, soll sie auch beweisen. {{unsigniert|188.98.217.58|15:53, 16. Okt. 2020 (CEST)}} | |||
== Optionale statische (graduelle) Typprüfung ab Python 3.5 == | |||
Aktuelle Python-Versionen ab 3.5 unterstützen die optionale Annotation von Objekten mit Datentypen. Daher wird in der Infobox vom englischen Artikel auch von "gradual Typing" gesprochen, mit [https://www.python.org/dev/peps/pep-0483 PEP 483] als Referenz. Und die Unterstützung davon wird in der Zukunft vermutlich nur wachsen. Mit der Bibliothek [http://www.mypy-lang.org/ MyPy] kann man seine Programme auch einer statischen Typprüfung unterziehen. Daher ist Aussage aus dem Artikel | |||
<blockquote>eine statische Typprüfung wie z. B. bei C++ gibt es nicht</blockquote> | |||
zu stark. Die Aussage ist auch nicht ganz falsch, per Voreinstellung ist keine statische Typprüfung eingebaut, außer man verwendet zusätzliche Bibliotheken, und sie ist ganz sicher nicht wie bei C++. Aber die Sprache selbst unterstützt die Bibliotheken zur statischen Prüfung bewusst. Daher würde ich diese Aussage relativieren und die optionalen Typ-Annotationen im Artikel erwähnen. --[[Benutzer:Elimik31|Elimik31]] ([[Benutzer Diskussion:Elimik31|Diskussion]]) 12:50, 16. Okt. 2020 (CEST) | |||
== Strukturierung durch Einrücken == | |||
Zitat: ''Für Programmierneulinge wird der Zwang zu lesbarem Stil aber als Vorteil gesehen.'' An dieser Stelle fehlen Belege, wer das als Vorteil sieht; auch der erwähnte Vorschlag von [[Peter J. Landin]] ist unbelegt (ist er auch in dessen biographischem Artikel). | |||
Von fehlenden Belegen abgesehen, ist dieser Satz ein seltsam flüchtiges Argument. "Programmierneulinge" bleiben einerseits nicht lange Neulinge und andererseits haben die meisten Pythonnutzer bereits Erfahrung mit anderen Sprachen. Python beansprucht ja ausdrücklich nicht, eine "Lehr-" bzw. "Ausbildungssprache" zu sein (wie [[Pascal (Programmiersprache)|Pascal]]). Also obigen Satz bitte belegen oder streichen! Besser noch einen Beleg zur "off-side rule" von Landin (hier oder dort) einfügen. Ganz apart wäre natürlich eine Quelle, die Anspruch und tatsächliche Wirkung der "off-side rule" untersucht und bewertet. Gruß, --[[Benutzer:Drahkrub|Burkhard]] ([[Benutzer Diskussion:Drahkrub|Diskussion]]) 14:46, 16. Okt. 2020 (CEST) | |||
: Glaube nicht, dass es so gemeint war, aber als jemand, der den Code von Programmierneulingen lesen muss, sehe ich es als Vorteil, wenn diese zu lesbarem Code gezwungen werden. Erfahrene Programmierer schreiben in den meisten Sprachen lesbar. Ob es für die Anfänger selbst hilfreich ist, ist diskussionsbedürftig. Aber, dass es ein Ziel der Sprache ist, lesbaren Code zu produzieren, steht ja schon oben im Artikel und sollte man hier nicht wiederholen. Übrigens, wie in jeder anderen Programmiersprache kann man auch in Python schwer lesbaren Code schreiben. Deswegen setzen viele Python-Projekte die Einhaltung von Stilvorgaben wie PEP8 vorraus. Dafür helfen Entwicklungsumbebungen, die Stilfehler automatisch markieren und auf Wunsch Code automatisch formattieren. Aber das selbe gilt auch für andere Programmiersprachen. Da läuft vielleicht nicht-indentierter Code theoretisch, aber die Indentantion von den Stilvorgaben gefordert und von der Entwicklungsumgebung meist automatisch eingefügt. | |||
--[[Benutzer:Elimik31|Elimik31]] ([[Benutzer Diskussion:Elimik31|Diskussion]]) 18:18, 16. Okt. 2020 (CEST). | |||
::Was wie gemeint war, glaubst Du nicht??? Aussagen in Artikeln müssen belegt sein - das ist der Diskussionspunkt - nicht das Thema Lesbarkeit durch Einrücken an sich. Wenn obiges Statement konkreten Autoren zugeschrieben werden kann, dann her mit dem Beleg; wenn es Studien oder gar Sekundärliteratur zu dem Thema "Zwang zu lesbaren Code" gibt, erst recht. Drumrummogeln durch Passivstil gilt nicht. --[[Benutzer:Drahkrub|Burkhard]] ([[Benutzer Diskussion:Drahkrub|Diskussion]]) 20:51, 16. Okt. 2020 (CEST) | |||
Korrektes Einrücken kenne ich noch aus der Zeit, als ich in COBOL programmieren mußte. Ist glücklicherweise schon lange her.--[[Benutzer:Jost Riedel|Jost Riedel]] ([[Benutzer Diskussion:Jost Riedel|Diskussion]]) 18:41, 16. Okt. 2020 (CEST) | |||
ich kann nur jedem empfehlen, sich mal https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements zu gemüte zu führen. da wird im detail angegeben, wo man wieviele leerzeichen eingeben soll. also auch an stellen, die im ggs. zur einrückung keinerlei auswirkung auf die programmausführung haben. humbug, in meinen augen. da wird mit vermeintlich besserer "lesbarkeit" argumentiert, obwohl dem erfahrenen programmierer klar sein sollte, daß "lesbarkeit von code" erstens nicht objektiv ist (sofern es nur um leerzeichen etc geht) und zweitens von anderen, viel wichtigeren faktoren abhängt. z.b. davon, daß man variablen, klassen und funktionen möglichst verständlich benennt. i, j und k sind als schleifenzähler in ordnung, aber ansonsten sollte man eine variable besser "mainWindow" als nur "w" benennen. reguläre ausdrücke sind ein nützliches konstrukt, aber einer "re.match" anweisung sieht man oft nicht an, nach welcher art ausdruck damit gesucht werden soll. ein kommentar mit einem beispielstring, der die suchkriterien erfüllt, kann da hilfreich sein. grundsätzlich schlecht ist auch, daß python förmlich dazu einlädt, globale variablen und funktionen einfach da zu definieren, wo es gerade paßt. wenn man in einer funktion dann eine variable definiert, die denselben namen hat wie eine schon existierende globale, kein problem. nichtmal eine warnung. das ist schon sehr schlecht gelöst. {{unsigniert|188.98.217.58|23:21, 16. Okt. 2020 (CEST)}} | |||
== Anonyme Namensräume? == | |||
"Anonyme Namensräume (sog. Closures) sind mit den o. g. Mechanismen in Python ebenfalls einfach möglich.". Anonyme Namensräume gibt es in C++, hier sind wohl eher anonyme Funktionen gemeint. Aber: Closures sind keinesfalls das Gleiche wie anonyme Funktionen. Zwar werden in vielen Sprachen Closures durch anonyme Funktionen realisiert, aber Closures können auch durch Funktionen mit Namen realisiert werden. Wie das Beispiel zeigt: Da gibt es nur Funktionen mit Namen.--[[Benutzer:Jost Riedel|Jost Riedel]] ([[Benutzer Diskussion:Jost Riedel|Diskussion]]) 22:42, 16. Okt. 2020 (CEST) | |||
Aktuelle Version vom 14. Juni 2024, 09:24 Uhr
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Python (Programmiersprache)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.
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
Meiner 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
Anders 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
switchin C/C++ odercasein 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
switchnicht böte. Mitmatchscheint 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,whileundifauf. Das stimmt so nicht bzw. es erweckt einen falschen Eindruck; man müsste mindestens auchtry…exceptundwitherwä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
Der 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?
Wiki 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."
Was 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)
