Dieser Artikel war am 16. Oktober 2020 der Artikel des Tages.

Archiv

/Archiv/1 · /Archiv/2

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 1080 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte.

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Ich denke, es wäre besser Python eher als Skriptsprache zu klassifizieren. Schließlich wird Python mehr interpretiert. Siehe hierzu auch Kategorie:Skriptsprache. --(nicht signierter Beitrag von 178.4.180.215 (Diskussion) 18:07, 6. Feb. 2018 (CET))Beantworten

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 *.pyc-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. --Winof (Diskussion) 14:34, 7. Feb. 2018 (CET)Beantworten

Ä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-malloc(...) und -free(...)). Und sonst noch ein paar kleinere Abweichungen vom Referenz-Python.

--arilou (Diskussion) 15:38, 3. Dez. 2018 (CET)Beantworten

Worauf genau bezieht sich Dein „nö“? Nichts von dem, was Du geschrieben hast, widerspricht dem, was ich geschrieben habe.

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. --Winof (Diskussion) 14:59, 16. Jan. 2019 (CET)Beantworten

"Nichts von dem, was Du geschrieben hast, widerspricht dem, was ich geschrieben habe." ~ Dann also en detail:

1. "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.
2. "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.
3. "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, ...).

--arilou (Diskussion) 16:46, 16. Jan. 2019 (CET)Beantworten

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.

Ü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 … --Winof (Diskussion) 19:19, 16. Jan. 2019 (CET)Beantworten

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.

--arilou (Diskussion) 09:43, 17. Jan. 2019 (CET)Beantworten

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. -ZT (Diskussion) 06:50, 14. Okt. 2019 (CEST)Beantworten

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! --Aristeas (Diskussion) 17:34, 17. Nov. 2019 (CET)Beantworten

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. --Diaspomod (Diskussion) 11:30, 18. Nov. 2019 (CET)Beantworten

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. --TheRandomIP (Diskussion) 17:09, 1. Sep. 2020 (CEST)Beantworten

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. --Diaspomod (Diskussion) 21:26, 1. Sep. 2020 (CEST)Beantworten

Gibt es dann vielleicht andere Quellen, die die mangelnde statische Typsicherheit explizit kritisieren? --TheRandomIP (Diskussion) 22:06, 1. Sep. 2020 (CEST)Beantworten

...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) --TheRandomIP (Diskussion) 14:35, 4. Sep. 2020 (CEST)Beantworten

Es geht um folgende Zurücksetzung von @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)

Mit Meinungsbild war vermutlich dieses gemeint: https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Nutzung_von_Daten_aus_Wikidata_im_ANR aus 2015 Der hier betroffene Punkt "Das Entfernen von Daten aus der deWP ... ist bis auf Weiteres unzulässig." wurde damals abgelehnt.

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. --Sebastian.Dietrich ✉ 00:43, 27. Mai 2020 (CEST)Beantworten

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.  @xqt 08:00, 27. Mai 2020 (CEST)Beantworten

Danke für diese Änderung. Aber wie kann dieser Unsinn verhindert werden, wo es haufenweise Einträge mit bevorzugtem Rang gibt?  @xqt 08:19, 27. Mai 2020 (CEST)Beantworten

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). --Sebastian.Dietrich ✉ 20:11, 29. Mai 2020 (CEST)Beantworten

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? --My2Cents (Diskussion) 14:30, 30. Jun. 2020 (CEST)Beantworten

"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. (nicht signierter Beitrag von 188.98.209.101 (Diskussion) 00:53, 16. Okt. 2020 (CEST))Beantworten

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 …
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.
Troubled @sset   ^{[ Talk ]}   07:02, 16. Okt. 2020 (CEST)Beantworten

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.[[1]] «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. ไม่เป็นไร (Valanagut) (Diskussion) 09:29, 16. Okt. 2020 (CEST)Beantworten

Keiner schreibt ein Fachbuch «Warum Python Scheisse ist».

Polemisch. Schon mal "Why x is bad" in eine Suchmaschine eingegeben? 185.69.244.136 13:56, 16. Okt. 2020 (CEST) --Beantworten

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. (nicht signierter Beitrag von 188.98.217.58 (Diskussion) 15:53, 16. Okt. 2020 (CEST))Beantworten

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 PEP 483 als Referenz. Und die Unterstützung davon wird in der Zukunft vermutlich nur wachsen. Mit der Bibliothek MyPy kann man seine Programme auch einer statischen Typprüfung unterziehen. Daher ist Aussage aus dem Artikel

eine statische Typprüfung wie z. B. bei C++ gibt es nicht

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. --Elimik31 (Diskussion) 12:50, 16. Okt. 2020 (CEST)Beantworten

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). 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ß, --Burkhard (Diskussion) 14:46, 16. Okt. 2020 (CEST)Beantworten

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.

--Elimik31 (Diskussion) 18:18, 16. Okt. 2020 (CEST).Beantworten

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. --Burkhard (Diskussion) 20:51, 16. Okt. 2020 (CEST)Beantworten

Korrektes Einrücken kenne ich noch aus der Zeit, als ich in COBOL programmieren mußte. Ist glücklicherweise schon lange her.--Jost Riedel (Diskussion) 18:41, 16. Okt. 2020 (CEST)Beantworten

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. (nicht signierter Beitrag von 188.98.217.58 (Diskussion) 23:21, 16. Okt. 2020 (CEST))Beantworten

"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.--Jost Riedel (Diskussion) 22:42, 16. Okt. 2020 (CEST)Beantworten