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? |
.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? --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. (nicht signierter Beitrag von 188.98.209.101 (Diskussion) 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 …
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)- 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)
- 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) --
- 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))
- Im Artikel steht, dass Python diesen Anspruch erhebt, nicht, dass es ihn zu 100 Prozent einlöst. Der Satz wäre dann und nur dann falsch, wenn Python diesen Anspruch gar nicht erheben würde. Ist das so?
Im Übrigen frage ich mich schon, warum Python auch im profesisonellen Umfeld für bestimmte Einsatzzwecke diese Verbreitung gefunden hat, wenn die Sprache dermaßenh unbrauchbar ist. Entwickler, die eine strenge Typisierung haben wollen, müssen dann eben eine andere Sprache verwenden.
Wenn ich im C/C++/C#-Bereich sehe, wie Klassen und Methoden mit ansonsten identischen Bezeichungen mal im MixedCase und mal im camelCase benannt (und dann womöglich noch inkonsistent überladen) werden und die Entwickler das schon mal durcheinanderbringen, ohne dass der Compiler eine Warnung ausgibt, stellt man fest, dass Warnungen auch nicht vor allen solchen Fehlern schützen. Wenn man in Projekten, in denen nicht auf eine strikte Typeinhaltung geachtet und viel mit impliziten Typ-Konversionen gearbeitet wird, dann die entsprechenden Compilerwarnungen aktiviert und plötzlich 5000 Warnings bekommt, kann man auch nicht sicher sein, ob die alle harmlos sind. Man muss die Sprachen einfach sinnvoll einsetzen. Gerade bei Python ist eine strikte Namenskonvention sinnvoll, dadurch werden viele dieser Fehler schon im Ansatz vermieden. Meine Entwicklungsumgebung warnt mich im Übrigen, wenn ich eine noch nicht verwendete Variable, Methode etc. eintippe, und ich kann dann entscheiden, ob ich hier wirklich ein neues Element einfügen will oder mich nur vertippt habe. Man kann auch eine Liste aller definierten Variablen mitführen und schon während der Entwicklung nach jedem Testlauf automatisch prüfen lassen, ob alle während der Ausführung dynamisch angelegten Variablen etc. auch tatsächlich vorhanden sein sollen.
Das verwechselte i und I kommt gar nie in die Produktion, wenn man sich an die elementarsten Regeln für professionelle Software hält, weil das bereits während der Entwicklungsphase spätestens durch einen Unit Test aufgefallen wäre (auch in Python darf man Unit Tests und andere automatisierte Testkonzepte anwenden).
Wir sind hier aber auf der falschen Seite für solche Diskussionen. Troubled @sset [ Talk ] 12:40, 18. Okt. 2020 (CEST) - Für die Interessierten: Python for C# Developers aus dem Code Magazine. (nicht signierter Beitrag von Troubled asset (Diskussion | Beiträge) 18:25, 18. Okt. 2020 (CEST))
- Im Artikel steht, dass Python diesen Anspruch erhebt, nicht, dass es ihn zu 100 Prozent einlöst. Der Satz wäre dann und nur dann falsch, wenn Python diesen Anspruch gar nicht erheben würde. Ist das so?
- 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))
- 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)
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 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)
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). 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)
- 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).
- 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)
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)
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))
- Die Aussage gilt, wenn auch nicht unbedingt objektiv, nur für das Einrücken. Das ist in meiner subjektiven Meinung neben anderen Faktoren schon eines der wichtigen Kriterien für die Lesbarkeit. Und Python erzwingt es eben als syntaktische Vorgabe. Bei sog. Neulingen, die davor nie programmiert haben und die Grundlagen erlernen, kann man das didaktisch positiv bewerten, da ein nicht eingerückter Code in Python niemals ausführbar ist und so keine Erfolgserlebnisse durch nicht formatierten Code entstehen. Man kann sicherlich eine Quelle dafür finden, die das bestätigt. Auch wenn es sich bei der Informatik um eine Naturwissenschaft handelt, gibt es da auch verschieden auswählbare Alternativen bei Problemlösungen, die man am Ende subjektiv aussucht. Man kann den Satz z.B. auch in eine abgeschwächte Formulierung überführen, die das subjektive Empfinden dabei klarstellt. --Diaspomod (Diskussion) 16:44, 17. 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.--Jost Riedel (Diskussion) 22:42, 16. Okt. 2020 (CEST)
- Würde "Anonyme Namensräume (sog. Closures)" durch "Closures" ersetzen, da die Begriffe wie gesagt keine Synonyme sind und es sich hier um Closures handelt. --Diaspomod (Diskussion) 16:31, 17. Okt. 2020 (CEST)
Taschenrechner
Mittlerweile scheint es auch Taschenrechner mit einer Implementation zu geben. Casio (FX-9860 GⅢ, https://edu.casio.com/products/graphic/fx9860g3/) und ti (84 Plus CE-T, 83 Premium CE Edition) stand auf den Geräten, die mir unterkamen und hierhin zu gehören scheinen — wobei Casio ja längst auch auf Geräten zu finden ist, auf denen sonst hp steht (z. B. hp 300S Plus vs. Casio 991 o. ä.). (nicht signierter Beitrag von 93.229.106.129 (Diskussion) 00:19, 8. Nov. 2020 (CET))