Diskussion:Python (Programmiersprache)/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Python (Programmiersprache)/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Python_(Programmiersprache)/Archiv/2#Thema_1

Literatur und Links

Sind das nicht arg viel Literatur- und Weblinks? Noch dazu weisen die Literaturlinnks manchmal auf offizielle Seiten des Verlages ohne Downloadmöglichkeit für das Buch, statt auf google-books, wo man das Buch lesen kann. --91.97.31.89 16:52, 1. Jan. 2011 (CET)

Ich habe zwei redundante Weblinks entfernt. Die Literaturliste ist ganz Ok, es befinden sich mehre Werke darunter, die ich persönlich für sehr gut halte. Aber bekanntlich haben unterschiedliche Menschen unterschiedliche Vorlieben und Bedürfnisse, deshalb ist etwas Auswahl gut. Die Liste sollte nicht übermäßig lang werden, aber das ist sie IMHO auch nicht.

Wenn Du Google-Books-Links haben willst, kannst Du sie ja hinzufügen.

-- Krille 19:00, 1. Jan. 2011 (CET)

Lizenz

Hallo!

Ich finde die Angabe in der Tabelle "Lizenz: Python License" nicht sehr hilfreich, zumal der Zielartikel nicht vorhanden ist. Wenn man der en-WP glauben kann, ist die Lizenz mit der GPL kompatibel. Ich denke, dass dieser Hinweis auch andere Leser noch interessieren könnte. --Liebe Grüße Crux 15:22, 22. Feb. 2011 (CET)

HILFE!?!?!?

Kann mir jmd. helfen? Ich bin zwar kein blutiger Anfänger mehr, aber ich komme mit manchen Begriffen nicht zurecht. Ist Python einfach oder eher schwerer zu erlernen? Für welche Art von Programm kann man Python verwenden? Welche Sprache ist einfacher zu erlernen? C++ oder Python ? Kann mir jmd. einen Link oder ähnliches geben, bei dem ich Befehle u.s.w. für die Sprache finde? Ich danke euch jetzt schon

--4pf3lkuch3n.321 (nicht signierter Beitrag von 89.204.137.176 (Diskussion) 10:49, 15. Jun. 2011 (CEST)) 

Zunächst ist das hier nicht der Ort solche Fragen zu stellen. Wikipedia ist eine freie Enzyklopädie und kein Diskussionsforum für die jeweiligen Themen.

Was die Fragen betrifft: Programmiersprachen miteinander zu vergleichen ist oft müßig. In diesem Fall ist die Antwort aber eindeutig. Mit Python erzielt man wesentlich schneller Erfolge als mit C++. Mit Python lässt sich das meiste auch programmieren. Web-Anwendungen, Programme, die auf Datenbanken zugreifen mit hübscher Benutzeroberfläche, praktische Hilfssoftware für den Desktop. Treiber, Betriebssysteme und grafisch aufwendige Spiele sind hingegen nicht Python's Domäne.

Hilfe, eine Übersicht über die gesamte Syntax und ein Tutorial findet sich in der mitgelieferten Python-Software. Was weitere Fragen bzgl. der Programmiersprache betrifft, sollten Sie das deutsche Python-Forum aufsuchen. --Aetas volat. 15:44, 15. Jun. 2011 (CEST)

Einrückung zur Blockbegrenzung

„Ihr Gebrauch von Einrückung zur Blockbegrenzung ist ungewöhnlich unter populären Programmiersprachen.“ – Machen das noch andere (populäre), und wenn ja, welche? --Mosmas 18:41, 26. Jul. 2011 (CEST)

Eine Liste findet sich hier in der englischen Wikipedia. Die Sprachen sind alle nur wenig populär. --Aetas volat. 03:19, 8. Aug. 2011 (CEST)

Keine dieser Sprachen taucht unter den ersten 10 und lediglich F# überhaupt im TIOBE-Index [1] auf - den ich hier mal als Anhaltspunkt für das Kriterium "populär" hernehme. Habe daher "ungewöhnlich" geändert in "einzigartig". --Mosmas 20:46, 21. Aug. 2011 (CEST)

deswegen ist das feature trotzdem nicht "einzigartig", bei allem Respekt. Der TIOBE-Index ist ein relativ fragwürdiges Mass für die "Popularität" von Programmiersprachen, und mindestens in der akademischen Welt sind Miranda und Haskell, die ebenfalls die offside rule implementieren, ausgesprochen populär. Die Kernfrage ist natürlich, was man als "populär" bezeichnen möchte. Das ist ein klarer Fall von POV, ich formuliere deswegen den Satz mal NPOV-mässig um. Gruss --Herbert Klaeren 10:09, 22. Aug. 2011 (CEST)

Finde ich gut so. --Mosmas 10:43, 22. Aug. 2011 (CEST)

Tote Links

Die Links in den Literaturangaben

• Mark Pilgrim: Dive Into Python. Springer, New York 2004. ISBN 1-59059-356-1 (Download verfügbar) - Link auf http://diveintopython.org/
• Mark Pilgrim: Dive Into Python 3. Springer, New York 2009. ISBN 1-4302-2415-0 (Download verfügbar) - Link auf http://diveintopython3.org/

verweisen nicht mehr auf Webseiten (Fehlermeldung: "Gone. The requested resource / is no longer available on this server and there is no forwarding address. Please remove all references to this resource." Bitte die Links aktualisieren oder entfernen.--Lahpemed 10:56, 19. Nov. 2011 (CET)

done - hättest auch selbst machen können... --Sebastian.Dietrich ✉

Galileo OpenBook

• Peter Kaiser, Johannes Ernesti: Python - Das umfassende Handbuch (freie Online-Version)

Das ist (Version 2.5) nicht mehr ganz aktuell und gilt zudem unter Python-Programmiern - leider - gemeinhin als schlechteste verfügbare Einführung. Leider, weil viele Einsteiger diese Quelle als erstes nutzen. Schaut mal in die einschlägigen Python-Foren, da wird das deutlich. --Ffprfrd 23:03, 30. Nov. 2011 (CET)

Versionstabelle

Was haltet ihr davon, eine Versionsgeschichte à la Ubuntu#Versionstabelle einzuführen? Was sich geändert hat kann man hier finden, aber auch teilweise in der Presse --Martin Thoma 07:34, 2. Okt. 2012 (CEST)

Defekter Weblink

• http://blog.snaplogic.org/?p=94 (Internet Archive)

– GiftBot (Diskussion) 07:20, 5. Okt. 2012 (CEST)

http://blog.snaplogic.com/?p=94 ist die neue URL. Da ein Blog wohl kaum vom Feinsten (Wikipedia:WEB) ist, habe ich ihn mal entfernt. --Martin Thoma 11:19, 5. Okt. 2012 (CEST)

Dieser Abschnitt kann archiviert werden. --Martin Thoma 11:19, 5. Okt. 2012 (CEST)

Strukturierung durch Einrücken / Beispiel in C

Hinweis: Die "Fakultätsfunktion in C (mit Einrückung)" ist als Beispiel insofern unglücklich gewählt, als gerade hier die Klammerung überflüssig ist und in solch einem Fall nicht einmal in Lehrbüchern verwendet wird.

So ziemlich JEDER würde das so formulieren:

int fakultaet(int x){
    if (x > 1)
        return x * fakultaet(x - 1);
    else
        return 1;
}

Die Klammerung erfolgt (dann zwingend) nur um einen Anweisungsblock, der syntaktisch an die Stelle der einzelnen Anweisung tritt.

Ed --217.251.202.245 18:47, 10. Dez. 2012 (CET)

Du schreibst: So ziemlich JEDER würde das so formulieren: Nein, auf keinen Fall. Dieser Stil wird zwar in der Tat von manchen Leuten praktiziert (prominentester Vertreter ist Linus Torvalds, wenn ich mich nicht irre, mit dem schlechtesten Argument ever: "Es passt mehr Code auf eine Bildschirmseite"), jedoch sind die Probleme, die daraus erwachsen, signifikant. Ich würde sogar sagen, das ist eigentlich der Stil eines Anfängers, der nicht einschätzen kann, wie schlecht das ist.

Weiterhin schreibst du: und in solch einem Fall nicht einmal in Lehrbüchern verwendet wird Der Stil, der in Lehrbüchern verwendet wird, ist oft unter aller Sau. Das kommt einerseits daher, dass manche Lehrbücher von Professoren geschrieben werden, und Professoren schreiben nur äußerst selten Code; und andererseits kommt die Vorgabe eines platzsparenden Stils nicht selten von den Verlagen, weil das kostengünstiger ist bei der Herstellung des Buches.

Ich empfehle, Bücher zum Thema Coding Style zu lesen. Da werden die Prinzipien schön deutlich erklärt, aus denen sich herleitet, dass ein klammerloser Stil in C schlecht ist. ʘχ (Diskussion) 15:08, 12. Dez. 2012 (CET)

Zur Kernfrage zurück: M. E. ist es nur wichtig ein Skript mit derselben Aufgabe in einer anderen Programmiersprache (C, C++ oder Java) da stehen zu haben, wo man den Unterschied zwischen Einrückung und "kompaktem" Quellcode und einem Quellcode mit Klammern und Deklaration sowie Initialisierung jeder einzelnen Variable sehen kann... --Michael Reschke (Diskussion) 17:35, 12. Dez. 2012 (CET)

Erscheint mir auch irrelevant. Der Unterschied wird doch hoffentlich deutlich… --Chricho ¹ ² ³ 01:40, 13. Dez. 2012 (CET)

Ich habe das im Artikel verwendete Code-Beispiel nicht kritisiert, sondern nur auf die dort überflüssige Klammerung hingewiesen. (Und die Klammerung sollte ja eben den Unterschied zu Pythons Einrückungen darstellen.) Aber wenn das C-Beispiel hier seinen Zweck erfüllt, ist's ja gut.

Bei meiner Aussage, dass so gut wie niemand die einzelnen Anweisungen klammert, bleibe ich selbstverständlich. Bitte mal selbst in der Literatur oder in Programmcodes umschauen! Das ist auch weder schlecht noch Anfängerstil. Und es erwachsen auch keine Probleme daraus. (Welche sollten das sein?)

Ed --79.224.212.175 01:28, 18. Dez. 2012 (CET)

Es veranschaulicht halt den Unterschied des Anweisungsblocks durch Klammerung auf der einen Seite und Einrückung auf der anderen. Im Übrigen würde man im Einklang mit Python Enhancement Proposal 8 die Kurzschreibweise auch in zwei Zeilen schreiben.  @xqt 10:13, 18. Dez. 2012 (CET)

Das ist richtig, aber es gibt noch mehr Gründe. Sie gehen aus der einschlägigen Literatur hervor.

@Ed: Warum fragst du mich nach den Gründen? In der Zeit hättest du ganz sicher bereits online rausfinden können, warum ich das behaupte. Und ich bin sehr sicher, dass du mich nicht als Welterklärer ansiehst, daher werde ich mich hüten und hier einen Vortrag über Coding Style halten. Nur soviel: Wieso verweist du auf anderer Leute Code? Ich meine, dass man durch gründliches Nachdenken und Abwägen aller Faktoren sehr wohl zu meinem Ergebnis kommt. Ich denke jedenfalls, dass guter Stil nicht durch Abstimmung erkannt wird, sondern durch eigenständiges Gebrauchen des eigenen Verstandes. In beliebige Programmcodes beliebiger Entwickler zu schauen ist das genaue Gegenteil. Oder soll man etwa deiner Ansicht nach eine Statistik erstellen, wie andere irgendwas machen, und dann der Mehrheit hinterher laufen (sofern sich eine solche überhaupt feststellen lässt)? Wenn also ein bestimmter Fehler weit verbreitet ist, dann sollte man den auch machen? Weil man dann ja eine gute Entschuldigung parat hat, wenns am Ende schiefgeht? Etwa diese hier: "Ich mache nur, was alle machen, ich hab damit nichts zu tun, und überhaupt habe ich keine Verantwortung für meine eigene Arbeit." Das meinst du ja wohl sicher nicht. ʘχ (Diskussion) 10:52, 18. Dez. 2012 (CET)

Wir wollen uns nicht gegenseitig vorhalten, was wir in welcher Zeit vielleicht (anderes) tun könnten. Jedenfalls deutest du in deiner Antwort nur (allgemein) deine Meinung an, nennst aber kein Sachargument, warum denn nun der konkrete Codierstil überhaupt schlecht oder gar fehlerhaft sein sollte. Oder umgekehrt: Welche Fehler und Risiken lassen sich denn nun gerade durch die zusätzliche Klammerung einzeiliger Anweisungen vermeiden? Um nicht mehr ging es.

An dieser Detailfrage nun sozusagen den Hebel der Ahnungs- oder sogar Verantwortungslosigkeit anzusetzen, ist aber schon sehr willkürlich. Und guter Argumentationsstil sieht anders aus.

Ed --79.224.209.65 00:49, 27. Dez. 2012 (CET)

Das tut aber hier gar nichts zur Sache, da dieser Artikel von Python und nich von C handelt. In diesem Beispiel soll ja der Unterschied in der Blockbildung durch Einrückung vs. Klammerung veranschaulicht werden. Man könnte auch Pascal nehmen und mit den Schlüsselwörtern begin ... end arbeiten. Für das Beispiel ist es doch unerheblich, ob einzeilige Blöcke verkürzt dargestellt werden können. Es ist nur ein Beispiel.  @xqt 10:58, 27. Dez. 2012 (CET)

Namensstreit

Es gibt offenbar gerade einen Streit um den Namen, in den Artikel dürfte es noch nicht reinpassen, aber wenn es hochkocht, dass es niemanden überrascht. http://pyfound.blogspot.ca/2013/02/python-trademark-at-risk-in-europe-we.html 212.90.151.90 10:29, 15. Feb. 2013 (CET)

Der Streit ist beendet. [2] --Kronf @ 01:03, 2. Mai 2013 (CEST)

Objektorientierung vollständig unterstützt

"Objektorientierte und strukturierte Programmierung werden vollständig unterstützt"

Das ist nicht richtig, da Python Datenkapselung nur simuliert. Private Variablen können in Python mit Unterstrichen __gekenntzeichnet werden, aber das ist nur ein Hinweis an den Programmierer "Do not touch". Bei echter Datenkapselung wird der Zugriff von der Sprache behindert, nicht von einem Verhaltensknigge. Python-Entwickler meinen zwar, man könne es auch in anderen Sprachen umgehen, das ist aber nur quasi-richtig, da man natürlich alles umgehen kann (zB die Quellen editieren, eine Klassen-Variable von private auf public ändern), was aber schon durchaus böswillige Intention erfordert. Python setzt hingegen allein auf Verhaltensregeln, nicht auf Compiler-Konstrukte.

Edit: Siehe dazu auch Diskussion hier: http://stackoverflow.com/questions/1641219/does-python-have-private-variables-in-classes

Ein Artikel, der Python vollständige Unterstützung von OOP unterstellt, sollte diesen Umstand reflektieren!--87.149.71.75 10:45, 23. Sep. 2013 (CEST)

Reflektieren ist das Schlagwort. Das kann man in Java sehr elegant, in Python noch kürzer und übersichtlicher. Dass man dadurch zumindest wissentlich den Schutz von privaten Variablen umgehen kann ist nur sinnvoll. Eine Intention muss in diesem Fall in beiden Sprachen gleichermaßen angenommen werden, böswillige sei dahingestellt. Jedoch verhindert Python den Direktzugriff sehr wohl.

  >>> class NaiveNerd:
  	def __init__ (self, forNsa, forMe): self.__forMe, self.forMe = forMe, lambda: self.__forMe.replace('secret', 'booh')
  >>> closedShell = NaiveNerd('guesswhat', 'my super secret')
  >>> closedShell.forMe(), closedShell._NaiveNerd__forMe # = Methode zum sicheren Zugriff, Direktzugriff nur via Reflektion
  ('my super booh', 'my super secret')
  >>> closedShell.__forMe # Direktzugriff so nicht moeglich (unterbunden durch Interpreter-Konstrukt, NICHT nur durch Konvetion)
  Traceback (most recent call last):
    File "<pyshell#59>", line 1, in <module>
      closedShell.__forMe
  AttributeError: 'NaiveNerd' object has no attribute '__forMe'

Ich hoffe mit dieser Erläuterung ist zumindest klar, warum aus Konsistenzgründen hier ähnliche Unterstelllungen wie etwas bei Java gemacht werden. Ob Objektorientierung eine sichere unumgehbare (Richtung Sandbox-Style) Kapselung bedeuten sollte, ist eine andere Geschichte die sicher nicht in der Python Welt allein geklärt werden kann. --Lmx613 (Diskussion) 03:27, 24. Sep. 2013 (CEST)

Box "Beeinflusst von"

Nicht auch COBOL? Diese Einrückungen musste man da genauso machen, man fing z. B. mit 01...xyz an, dann kam eingerückt 03...xyz und 05...xyz sukzessive (falls benötigt). Selbst wenn sich das, was ich eben beschrieben habe, auf den Deklarationsteil (<VARIABLE> ... (PIC(...))) bezieht, hat man es bei den IFs (z. B. Stufenwechsel) im "Implementationsteil" - so würde man es in Java nennen :) - genauso gemacht. -andy 77.190.34.102 15:21, 7. Nov. 2013 (CET)

dem kann ich nicht ganz folgen. Das hat doch nichts mit Strukturieren durch Einrücken zu tun, sondern damit, dass in COBOL (ähnlich wie in FORTRAN auch) bestimmte Spaltenpositionen der Lochkarten für bestimmte Zwecke reserviert waren. Oefe (Diskussion) 00:28, 8. Nov. 2013 (CET)

Codebeispiel "Fakultät ohne Einrückung"?

Der Codeschnipsel unter "Die Fakultätsfunktion ohne Einrückung in Python" ist falsch, oder? Verdreht?

Da steht:

def fakultaet(x): return x * fakultaet(x - 1) if x > 1 else 1

Sollte es nicht sein

def fakultaet(x): if x > 1 return x * fakultaet(x - 1) else 1

Bin Anfänger, deshalb nur als Frage! (nicht signierter Beitrag von 193.99.77.121 (Diskussion) 11:30, 6. Dez. 2013 (CET))

Nein, ersteres ist richtig. Bei Python kann man in eine Zeile schreiben "a=b if c else d". Das macht den Code in den Fällen übersichtlicher, in denen der else-Fall weniger komplex/wichtig ist, da "a=b ..." direkt ins Auge fällt. Ob das auch bei obigem Beispiel noch zutrifft, dass damit die Lesbarkeit verbessert wird, mag jeder für sich selbst beurteilen.  — Felix Reimann ⚕ 13:07, 6. Dez. 2013 (CET)

vielen Dank! :-)

Das Beispiel zeigt doch den ternären Operator. Code ohne Einrückung ist eben nicht möglich. Gewiss kann man auch Einzeiler produzieren getrennt durch Semikolon aber eben keine Schleifen oder IFs. Ich finde das Beispiel etwas überflüssig.--Darktrym (Diskussion) 17:42, 23. Nov. 2014 (CET)

Dementsprechend angepaßt.  @xqt 07:28, 24. Nov. 2014 (CET)

Codebeispiel Quicksort

Das Beispiel mit Listennotation ist zwar kürzer geschrieben, aber von der Laufzeit schlechter, da hier zweimal über die Liste iteriert wird, bei der Version mit for nur einmal. Sollte man das nicht erwähnen?

Mydalon (Diskussion) 10:37, 11. Nov. 2014 (CET)

Ich habe einen Hinweis auf das schlechtere Laufzeitverhalten hinzugefügt, wenn es Einwände gibt sollten die hier diskutiert werden.

Mydalon (Diskussion) 13:29, 14. Nov. 2014 (CET)

Literatur

Könnte mir jemand etwas mit Belegen zur Hand gehen? Von den im Abschnitt Literatur genannten Werken sind mir leider nicht allzu viele zugänglich. MfG Chewbacca2205 23:57, 12. Aug. 2014 (CEST)

Der Abschnitt Literatur enthält viel Literatur aus den frühen 2000ern. Gerade im IT-Bereich ist das durchaus schon ältere Literatur. Das gilt besonders, wenn man beachtet, dass Python eine sich noch recht schnell entwickelnde Sprache ist. Anfang der 2000er galt dies selbst noch für Python 2.X. Sofern diese Bücher also nicht aus sonstigen Gründen von größerer Bedeutung sind sollten sie wohl entfernt werden, da sie für den heutigen Ein- oder Umsteiger keinen zu großen Wert mehr haben. --TobiasVetter (Diskussion) 20:43, 11. Mai 2015 (CEST)

Ja, da hast du Recht. Rund die Hälfte der Werke ist schon recht alt, da können sicherlich einige rausgenommen werden bzw. es können die aktuellen Auflagen nachgetragen werden. Chewbacca2205 (D) 08:44, 12. Mai 2015 (CEST)

Geschwindigkeitsvergleich

Pythoniker finden Lösungen ohne Java dreimal so schnell wie mit Python. (nicht signierter Beitrag von Wiki lofi (Diskussion | Beiträge) 09:50, 25. Aug. 2015 (CEST))

Sieht nach einem syntaktisch korrekten Satz aus. Aber es hapert an der Semantik: Ich verstehe kein Wort.  @xqt 14:52, 25. Aug. 2015 (CEST)

Es kann sein, dass es Compiler mit Optimierungen gibt, die erstmal unverständlich sind - man kann zB das Verhalten des Prozessors beim Verschieben vom Cache in die Register berücksichtigen, wenn man sowas wie STRUCT oder OBJECT verwendet - Prozessoren können so designet sein, dass das am schnellsten geht, wenn die im Speicher nebeneinander sind. 2003:74:F7B:6CF7:4138:E244:3545:D53F 11:13, 25. Apr. 2016 (CEST)

Gegenargument, dagegen, das so zu machen, ist, dass evtl nicht bemerkt wird, wie kompliziertere Dinge optimiert werden. 2003:74:F7B:6CF7:4138:E244:3545:D53F 13:04, 25. Apr. 2016 (CEST)

Versionen

In der Infobox steht als aktuelle Version:

• 3.5.1 (6. Dezember 2015),
• 2.7.11 (5. Dezember 2015)

Das finde ich ein wenig komisch. Warum sind zwei verschiedene Versionen aktuell? Noch dazu welche mit einem großen Sprung? Im Text habe ich keine Erklärung dafür gefunden. --87.140.192.0 21:05, 1. Jan. 2016 (CET)

Python 3.5.1 ist die aktuelle Hauptversion. Weil beim Versionssprung auf Python 3 viel an der Sprache geändert wurde, was dazu führte, dass mit früheren Python-Versionen geschriebene Skripte nicht mehr lauffähig sind, beschloss man wegen der Abwärtskompatibilität, die letzte Python-2er-Version, 2.7, weiter mit Updates zu versorgen, bis alle wichtigen Bibliotheken (auch die von Dritten) auf Python 3 umgestellt wurden. --Chewbacca2205 (D) 21:22, 1. Jan. 2016 (CET)

Entwicklungsgeschichte

Also für einen lesenswerten Artikel halte ich den Abschnitt "Entwicklungsgeschichte" für sehr unzureichend. Ich erfahre zwar ausführlich nach was Python benannt wurde, aber das wars auch schon. Was sich zwischen den Versionen groß geändert hat, erfährt man fast gar nicht. Es muss nicht gleich so ausführlich wie en:History of Python sein, aber das hier ist schon sehr mager. Leider kann ich dazu noch nichts beitragen, da ich erst am Anfang von Python stehe (und mich hier informieren wollte...). Siehe auch: Versionsgeschichte von PHP --195.192.205.201 03:47, 2. Apr. 2017 (CEST)

Ist "py" tatsächlich die drittwichtigste Sprache der Welt ?

Es fehlen Hinweise auf VErbeitungsgrad und Wichtigkeit der Sprache.

Laut neuer Forschung (kommerziell betrieben leider nur) soll Py die Nummer 3 der Welt sein.

Wahr oder "fake news" ? --91.60.158.122 13:10, 20. Jun. 2017 (CEST)

Das fehlt hier so wenig wie in anderen Artikeln zu Programmiersprachen, umso mehr fehlt eine Definition für "wichtig". Ganz abgesehen davon, dass es sich ständig ändert, ich würde daher sagen "fluid news" und also nicht eben pflegeleicht. Für diese beeindruckenden Rankings/Marketing-Gags hast du doch reichlich Anlaufstellen im Web, dafür brauchst du keine Enzyklopädie. Geeigneter sind hier konkrete Beispiele für die Verwendung und genau das steht im Artikel. Es hilft und reicht, die Popularität der Sprache grob einzuordnen. -ZT (Diskussion) 14:38, 20. Jun. 2017 (CEST)

Literatur & Weblinks zu 3.6

Gibt es dazu schon was? Ist die aufgeführte alte (3.0) Doku noch zu gebrauchen? -- 2A02:8108:8640:2418:BD0D:B150:5273:A71 18:52, 18. Okt. 2017 (CEST)

Pythons Relevanz fürs Scientific Computing

Was meiner Meinung nach wirklich fehlt, ist ein Hinweis auf Pythons Relevanz im Bereich Scientific Computing sowie Machine Learning. Neben einigen proprietären Programmen wie Matlab, Mathematica etc. hat Python inzwischen mit dem SciPy Ökosystem und der Anbindung an TensorFlow einen sehr hohen Stellenwert in Forschung und Lehre sowie in der Industrie. --(nicht signierter Beitrag von 2003:46:AD7F:1572:2677:3FF:FE42:E5EC (Diskussion) 23:27, 4. Jan. 2018 (CET))

deepcopy-Problematik

Ein Kritikpunkt an Python, der in vielen Tutorials besprochen wird (siehe [[3]] ) ist das unintuitive Standardverhalten bei Zuweisungen veränderlicher Objekte (deepcopy-Problematik). Kurz zusammengefasst wird folgendes kritisiert: Eine Variable im Quelltext ist nicht GLEICH einem Objekt, sondern referenziert nur auf ein Objekt. Dadurch können mehrere Variablen auf das selbe Objekt verweisen, zB a und b. Wird dieses Objekt durch den Zugriff über a geändert, kommt man nun auch über b auf den geänderten Wert. Zum Beispiel würde a=[1,2] ; b=a ; a[0]=0 zu b=[0,2] führen. Hierbei ist zu beachten, dass nur veränderliche Objekte dieses Verhalten standardmäßig zeigen, da nur diese wirklich geändert werden können. Nicht veränderliche Objekte (zB integer oder tupel) werden immer neu angelegt und nicht verändert, wodurch diese Problematik nicht auftritt (bzw wodurch sich die Problematik verschärft, da man eigentlich immer sehr genau darauf achten muss, was für einen Datentypen man gerade hat). Insgesamt haben wir also veränderliche Objekte, deren Variablen sich eher wie Pointer verhalten und nicht veränderliche Objekte, deren Variablen sich wie das Objekt selbst verhalten. Wie die Tutorials sagen, widerspricht dieses Verhalten der Intuition.

Leider geht die Problematik noch tiefer: Ein Hauptkonzept des sauberen Programmierens, das u.a. auch die Grundlage der objektorientierten Programmierung bildet, ist die Datenkapselung. Dabei wird einem bestimmten Programmabschnitt (zB einer Funktion) nur der Zugriff auf bestimmte Speicherbereiche (in Python-Sprache: bestimmte Daten-Objekte) erlaubt, wodurch das Programm über eine Liste von Funktionsaufrufen im Hauptbereich (in C: main) einfacher verständlich ist als ein "Spagetticode" ohne Struktur. Im Wesentlichen sieht man so schneller, welche Programmabschnitte sich über welche Variablen beeinflussen können. Durch die Loslösung von einer Äquivalenz von Objekt und Variablenname, kann man nun nur noch sagen, auf welchen Speicherbereich eine Funktion zugreift, sieht aber nicht mehr schnell, ob auch über andere Variablen in anderen Programmabschnitten Zugriffe auf den selben Speicherbereich auftreten. Man müsste (im besten Fall) nach JEDER Stelle im Quelltext suchen, an der eine Variable auftaucht, um zu wissen auf welche anderen Programmabschnitte der eine Funktionsaufruf denn Auswirkungen haben könnte. Dies erhöht selbstverständlich die Komplexität, Fehleranfälligkeit und Wartbarkeit enorm. Nicht gewollte Auswirkungen auf andere Programmbereiche verlaufen überdies ohne Fehlermeldung.

Dieses Verhalten ist ähnlich zur alten Pointer-Problematik: Wenn Pointer erlaubt sind, gibt es auch die Möglichkeit über verschiedene Variablen (die Variable selbst und alle Pointer auf diese Variable) auf den selben Speicherplatz zuzugreifen, wodurch einerseits gewisse Compileroptimierungen nicht mehr zulässig sind (siehe Geschwindigkeitsunterschiede Fortran vs C, für Python aber wirklich nicht relevant ;) ) und andererseits auch Querverweise auf andere Programmabschnitte auftreten können! Allerdings werden Pointer als "Warnung" meist speziell gekennzeichnet (*p &p), was bei Python nicht der Fall ist. Generell gibt es auch nur recht spezielle Routinen, bei denen Pointer als elegant gelten...sie kommen eben eher aus der Assemblerzeit und sollten von einer höheren Programmiersprache eher vermieden/verboten werden (so wie in Java, Ada, C#, Visual Basic, .NET usw.). In C/C++ sind ungewollte Pointer-Querverweise eine häufige Fehlerquelle.

Diese Kritik, zumindest eine Zusammenfassung des ersten Abschnittes über das unintuitive Verhalten, sollte im Artikel aufgenommen werden um die Vor- und Nachteile von Python besser herüberzubringen! (nicht signierter Beitrag von 77.181.174.108 (Diskussion) 14:46, 21. Jan. 2018 (CET))

Dass Variablen Referenzen sind (wie übrigens auch in etlichen anderen Sprachen), muss man als Anfänger natürlich lernen, und das passiert i. allg. ziemlich rasch. Die meisten Tutorien bringen dies einem spätestens bei der Besprechung des „is“-Operators und dessen Unterschied zu „==“ bei. Ob man es als Nachteil (oder „Kritikpunkt“) sehen mag, ist Ansichtssache; ich persönlich finde diese Eigenschaft von Python eher hilfreich als hinderlich, da sie Möglichkeiten eröffnet, die es in anderen Sprachen nicht gibt. Ich finde es auch ausdrücklich nicht „unintuitiv“ (und so wird es von den mir bekannten Tutorien und Lehrbüchern auch nicht dargestellt). Möglicherweise ist es für einen Mathematiker unintuitiv, oder für jemanden, der vorher in BASIC programmiert hat. Den Vergleich mit der Pointer-Problematik, wie man sie etwa von C kennt, halte ich für an den Haaren herbeigezogen. --Winof (Diskussion) 08:54, 22. Jan. 2018 (CET)

Intuitiv soll in diesem Zusammenhang heißen, dass jemand der noch nie etwas mit einer speziellen Fragestellung zu tun hatte, diese Fragestellung "intuitiv" richtig beantwortet. Hier sagt Winof selbst (sowie die entsprechenden Kapitel in der Literatur), dass ein Anfänger zuerst lernen muss, dass sich MANCHE Variablen auf eine Weise verhalten, die er (intuitiv) nicht erwartet hätte. Natürlich wird jemand, der sich in Python (oder generell schon einmal in die Problematik zB in C) eingearbeitet hat verstehen, was hinter veränderlichen und nicht veränderlichen Variablen steht. Die Kritik ist aber, dass die Einarbeitung in die Problematik in einigen anderen Programmiersprachen NICHT NOTWENDIG ist, wenn dort die innere Struktur der Datentypen einheitlich und halt intuitiv gestaltet ist und nach außen nicht weiter beachtet werden muss! Schlägt jemand ein besseres Wort als "unintuitiv" für die Beschreibung der "deepcopy-Problematik" vor?

Ich befürchte, dass wir bei dem Vergleich mit Pointern Kommunikationsprobleme haben. Vielleicht nenne ich es eher die Problematik, dass es mehrere Referenzen auf einen Speicherplatz gibt!? Vielleicht wird die Problematik in (siehe [[4]] ) besser deutlich!! Dort werden die von Winof als "eher hilfreich" beschriebenen Möglichkeiten über "Auch wenn manche Programmierer bewusst Seiteneffekte zur Lösung ihrer Probleme einsetzen, wird dies im Allgemeinen als schlechter Stil betrachtet." kritisiert. Die Kritik hier ist, dass ÜBERHAUPT Seiteneffekte auftreten können! Das Paradigma der strukturierten Programmierung und der strengen Datenkapselung wurde in Python also nicht umgesetzt. Aus meiner Sicht ist dies der stärkste Kritikpunkt an Python überhaupt. (nicht signierter Beitrag von 92.227.119.153 (Diskussion) 23:26, 22. Jan. 2018‎)

Du wirfst da mehrere unterschiedliche Dinge durcheinander. So etwas wie eine „deepcopy-Problematik“ kann ich nicht erkennen. Dass es veränderbare und unveränderbare Objekte gibt (mutable und immutable), ist ein Feature, kein Bug. Und wenn man einmal verstanden hat, warum diese Design-Entscheidungen in der Sprache getroffen wurden, dann ist es auch sofort einleuchtend und logisch. Das hat übrigens nichts mit der „inneren Struktur der Datentypen“ zu tun; die ist durchaus einheitlich. Das Tutorial auf python-kurs.eu erklärt es übrigens eher schlecht (und scheint auch sonst nicht besonders gut zu sein); das darf man natürlich nicht Python selbst anlasten. Es sollte auf jeden Fall klargestellt werden, dass „=“ eben kein Wert-Zuweisungs-Operator ist, sondern ein Referenz-Bindungs-Operator. Zitat vom Tutorial auf docs.python.org: „Assignments do not copy data – they just bind names to objects.“

Mehrere Referenzen auf einen Speicherplatz gibt es in nahezu allen Sprachen, von C bis Java. Natürlich ist Python nicht nebeneffektfrei, aber auch das gilt für nahezu alle Sprachen (ausgenommen sind nur wenige funktionale Sprachen, die vergleichsweise geringe Verbreitung haben). Es gibt ja auch globale Variablen (ebenfalls eine Design-Entscheidung) – wollte man all dies „sauber“ machen, bräuchte man andere Paradigmen und Konstrukte wie z. B. Monaden, aber dann ist Python einfach die falsche Sprache. Auch die Tatsache, dass es keine erzwungene Privatheit (etwa bei Methoden und Objektdaten) gibt, war eine bewusste Entscheidung beim Design der Sprache, die ja eher auf Kooperation und Dynamik als Grundprinzipien setzt. Dadurch ist natürlich keine strenge Datenkapselung gegeben, was aber nichts mit Pointern zu tun hat. --Winof (Diskussion) 12:58, 23. Jan. 2018 (CET)

Unsere Diskussion geht anscheinend um die Vor- und Nachteile von zwei grundsetzlichen Implementierungen von Verhalten von Variablen: 1. Eine Variable wird als Referenz auf ein Objekt betrachtet. 2. Eine Variable wird direkt als ein Wert betrachtet. Die Kritik, die aus meiner Sicht in den Artikel aufgenommen werden sollte, ist die, dass Python Variablen grundsätzlich als Referenz implementiert (diese Kritik richtet sich auch an viele andere Sprachen wie C/C++. Das heißt aber nicht, dass es keine berechtigte Kritik ist!). In Python werden zusätzlich manche Variablen (die unveränderlichen Variablen) wie Werte behandelt ohne den Unterschied zwischen veränderlichen/unveränderlichen Variablen kenntlich zu machen (wie bei Pointern in C/C++...Zusammenhang zu Pointern kommt gleich).

Ich befürchte, wir reden aneinander vorbei, daher möchte ich nochmal etwas genauer werden, was ich meine:

In Assembler sind Variablen (bis auf Zugriffe auf die Register, die wir hier getrost beiseite lassen können) immer Zeiger auf eine Adresse im Arbeitsspeicher. Also ist die Struktur hinter einer Variablen auch immer ein Zeiger/Pointer/Referenz (grob gesprochen, natürlich steckt hinter einem echten Pointer meist noch die Info auf welchen Datentypen gezeigt wird usw.. Mit Referenz meine ich im Folgenden aber einfach ein Verweis auf einen Speicherbereich ohne zusätzliche Strukturen/Daten).

Von einer Referenz erwartet man: Seien a, b, Objekt_1 und Objekt_2 Referenzen. Aus a=Objekt_1; b=a; b=Objekt_2; folgt a=Objekt_2;. Dabei ist das "=" auch ein Referenz-Bindungs-Operator. Dieses Verhalten sieht man bei veränderlichen Variablen in Python (siehe Beispiel ganz oben). Dieses Verhalten von Variablen entspricht dem Hardwareverhalten...was man natürlich auch auf gewisse Weise, mit dem richtigen Wissen als intuitiv bezeichnen kann.

Aus der (Schul-)Mathematik ist es jeder gewohnt direkt mit Zahlen, oder aber mit Variablen zu rechnen, die direkt einer Zahl entsprechen (oder einem Vektor, Matrix ...). Daher ist es sicherlich als FÜR JEDEN intuitiv anzusehen, wenn sich Variablen in einem Quellcode ähnlich verhalten wie feste Werte. Dass eine Variable technisch gesehen die Adresse eines Speicherbereichs ist und der Wert erstmal in ein CPU-Register geladen werden muss um wirklich auf einen Wert zuzugreifen, ist schön zu wissen...aber man sollte sich möglichst nicht mit solchen hardwarenahen Dingen beschäftigen müssen. (wenns nicht gerade um high-performance computing geht, aber selbst da braucht man typischerweise keine Referenzen (siehe MODERNES Fortran)).

In einer höheren Programmiersprache geht man daher normalerweise hin und "versteckt" das Referenz-Verhalten von Variablen. Man erhält, dass aus a=5; b=a; b=6; folgt a=5;. Dies ist übrigens auch in Python bei unveränderlichen Objekten so. Man könnte nun sagen: Hey, das "=" sieht doch auch in Python aus wie ein Wert-Zuweisungs-Operator. Aber man muss sich hier überlegen: "Nein!" In Python möchte man anscheinend hardwarenahe, performanceorientierte Listen haben (was so gar nicht zum Konzept von Python passt). Also muss man die Variablen hier als Referenzen auf Objekte sehen, die ständig neu erzeugt und vernichtet werden.

Also: Vorteile von "Variable ist Referenz": -hardwarenah und daher schneller für manche Berechnungen -Praktischer bei speziellen Implementierungen, zB (verkettete) Listen in Python ... verkettete Listen sind übrigens das parade-anwendungsbeispiel für Pointer...

Nachteile von "Variable ist Referenz": -unintuitiv für Leute, die sich nicht mit Hardware auskennen -verbietet schlechten Programmierstil (Seiteneffekte) nicht ... mir ist klar, dass das kein Bug ist. Es kann dennoch ein in Kauf genommener Nachteil einer Implementierung sein

Siehst du diese Nachteile? Im Endeffekt solltest du dich auch fragen, ob solch eine Kritik nicht eine Daseinsberechtigung hat, auch wenn du sie nicht als wichtig empfindest... Autoren von Lehrmaterial sehen diese Kritikpunkte auf jeden Fall auch...

Zu den globalen Variablen: Ja, da wird auch die Datenkapselung zerstört... Allerdings kann man normalerweise recht einfach nachgucken, welche globalen Variablen existieren (und eine ausgedehntere Verwendung von globalen Variablen wird auch allgemein hin als unguter Stil betrachtet.) Das wichtige ist hier der Kosten-Nutzen Faktor. Um alle Referenz-Variablen auf ein Objekt zu finden (zB zum debuggen), muss man im gesamten Quelltext zuerst nach der ursprünglichen Variablen suchen, falls Referenz-Variablen gefunden wurden, muss man auch nach diese den gesamten Quellcode durchsuchen usw. Bei zu starker Verwendung des "Features" der Referenzen, kann man den Code recht schnell nicht mehr durchschauen. Bei globalen Variablen ist dies nicht so krass und der Nutzen ist wesentlich größer.

Vielleicht ist auch dies hier unser Kommunikationsproblem: Es gibt zwei früher konkurrierende Sprachen: Fortran und C. C ist sehr Hardwarenah und hat sich stark auf Pointer gestützt (wurde auch als Super-Assembler bezeichnet). C wurde entwickelt um Betriebssysteme (unix) zu programmieren und hat sich mit dem Erfolg von unix (zum Leid vieler) durchgesetzt. Mit dem Vorwissen aus C/C++ über Pointer und der häufigen Verwendung dieser, vermute ich, dass viele Leute die Eleganz von einer gewissen Hardware-Abstraktion in Bezug auf Referenzen gar nicht kennen und so auch natürlich nicht zu schätzen wissen. Fortran hat Pointer (und alle als Referenzen erkennbaren Objekt) vermieden und so eine gewisse Hardwareabstraktion hinbekommen, wodurch es als erste höhere Programmiersprache gilt (und als eine der performantesten mit einigen Vorteilen gerade zum Thema Mehrfachreferenzen gegenüber C/C++). Wie das so ist, gab es zu viele verschiedene Parteien die bei der Entwicklung von Fortran mitbestimmen wollten, sodass Fortran zwischenzeitlich hoffnungslos veraltet war und so seinen schlechten Ruf wegbekommen hat. Ich befürchte, die Idee das eine Hardware-Abstraktion bei Variablen durchaus gut funktionieren kann, ist mit Fortran gestorben :( Heutzutage ist Fortran übrigens eine der modernsten Sprachen mit zB direkter Implementierung von Parallelisierung (neben MPI und OpenMP). (Nur als Info: Ich schreibe dies nicht aus Nostalgie!) Vielleicht liegt unser Missverständnis darin, dass du eine Sprache wie Fortran nicht kennst und damit die Vorteile einer erzwungenen strikten Datenkapselung nicht zu schätzen weißt?! Da eine strikte Datenkapselung als guter Programmierstil gilt, ist der lasche Umgang mit diesem Thema in Python zu kritisieren. (nicht signierter Beitrag von 92.227.224.45 (Diskussion) 01:18, 24. Jan. 2018‎)

Ich habe absichtlich ein paar Tage verstreichen lassen, um nicht im Affekt zu antworten, da ich es als (gelinde ausgedrückt) grob unhöflich empfand, dass Du Deine vorhergehende Antwort inhaltlich verändert und teilw. gelöscht hast, nachdem ich darauf geantwortet hatte. Das ist jetzt natürlich nicht unbedingt motivierend, mich noch weiterhin damit auseinanderzusetzen.

Jedenfalls kann ich Dir versichern, dass ich so ziemlich jede Programmiersprache kenne, die in den letzten 35 Jahren nennenswerte Verbreitung hatte, einschließlich Fortran (wobei ich dies nicht gerade für ein gelungenes Beispiel halte). Offenbar kennst Du Dich nicht besonders gut mit Python aus; das sieht man schon daran, dass Du Referenzen (die nicht „hardwarenah“ sind) mit Pointern gleichsetzt – es ist nicht das gleiche; außerdem ist Dein Beispiel mit Objekt_1 usw. falsch, und verkettete Listen sind in Python gerade kein Paradebeispiel. Möglicherweise bist Du auch alten Programmierparadigmen, die eine strikte compilerseitige Kapselung erfordern, so verhaftet, dass Du Dich anderen nicht ausreichend öffnen willst. Wenn Du ein Problem mit Referenzen (oder Delegates, ein Konzept mit verwandtem Hintergrund) hast, dann richtet sich Deine Kritik gegen fast alle modernen Programmiersprachen. Und übrigens: Fortran kennt natürlich Pointer – zumindest Fortran 95; mit späteren Versionen habe ich mich mangels Bedeutung nicht mehr beschäftigt, und an Fortran 77 kann (und will) ich mich diesbezüglich nicht erinnern.

Aber so langsam ist diese Diskussion hier ohnehin fehl am Platz. Sie gehört eher in ein Forum über Programmiersprachendesign. --Winof (Diskussion) 15:19, 1. Feb. 2018 (CET)

Anscheinend habe ich einen Teil des alten Beitrages mit dem neuen überschrieben, so dass der neue Beitrag teilweise doppelt auftauchte und der alte vollkommen unsinnig geworden ist. Ich habe den ursprünglichen alten Beitrag wieder hergestellt. Entschuldige bitte! Auch für die Vermutung, dass du dich nicht mit Fortran auskennst, möchte ich mich entschuldigen. Das sollte keine persönliche Beleidigung sein, sondern dir klar machen, dass wir unterschiedliche Sprachen gewöhnt sind und daher die Kommunikation einfacher fallen würde, wenn du versuchen würdest dich in einen Fortran Programmierer hineinzuversetzen, so wie ich versuche, mich in einen C/C++ Programmierer ?? hineinzuversetzen. Ich hatte das Gefühl, dass du meine Beiträge nicht versuchst zu verstehen...aber das gleiche Gefühl hast du anscheinend auch von mir und wir sollten nicht aggressiv werden.

Ich stimme dir zu, dass diese Diskussion hier so nicht hingehört. Ich habe versucht, die Kritik an Python etwas besser auf den Punkt zu bringen, was aber durchaus so explizit (soweit ich weiß) nirgends steht. Es geht in der Wikipedia nicht um persönliche Meinungen, daher denke ich, dass wir uns recht strikt an Quellen halten sollten und etwa so etwas in den Artikel unter "Kritik" gehört:

Das Verhalten beim kopieren von Daten wird als "ungewöhnlich im Vergleich zu anderen Programmiersprachen" kritisiert, was zu "verblüffenden und verwirrenden Erfahrungen" beim programmieren führen kann [[5]]. Zum Beispiel führt a=[1,2]; b=a; a[0]=0; zu b=[0,2]. Durch dieses Verhalten kann es auch zu ungewollten Seiteneffekten bei Funktionsaufrufen kommen [[6]].

Ich habe noch einmal mit Arbeitskollegen (meist promovierte theor. Physiker) geredet, die mir bestätigt haben, dass sie zu Beginn auch Programmfehler aufgrund des standardmäßigen flachen kopierens hatten und dies als deutlich unintuitives Verhalten ansehen. Dies ist eine konkrete, hilfreiche und von verschiedenen Seiten geäußerte Kritik, die den typischen Leser (wohl ein Python-Anfänger?!) des Wiki-Artikels interessieren wird.

Zu deiner Antwort: Ja, es gibt auch in Fortran Pointer, aber diese gelten dort meist als unschön und sollten vermieden werden! Und ja, ich befürchte du hast recht: Ich hänge an den "alten" Programmierparadigmen der strikten Datenkapselung. Die Frage ist allerdings, ob hier "alt" nicht eher durch "vergessen" oder "vernachlässigt" ersetzt werden müsste. Aus meiner Sicht hat sich bezüglich Datenkapselung ein schlechter Standard durchgesetzt, der mit Python durch das standardmäßige flache kopieren aus reinen Performancegründen (was eigentlich nicht zu Python passt) noch ein Stück weiter heruntergezogen wird. Natürlich haben Sprachen die zum neuen Standard werden häufig weit mehr Vorteile als Nachteile, das sehe ich auch bei Python. Aber die Nachteile sollten klar kommuniziert werden!

Was hat flaches kopieren mit Datenkapselung zu tun? Durch flaches kopieren b=a werden aus einer Variable a, über die der Programmierer auf EINEN Speicherbereich zugreifen kann, nun (standardmäßig) zwei Variablen a und b. Es wird doppelt so aufwändig nachzuvollziehen, was mit dem Wert auf dem EINEN Speicherplatz passiert und es kann eventuell von sonst vollständig unabhängigen Programmabschnitten auf den EINEN Speicherplatz zugegriffen werden. Solch eine fehlende Kapselung gibt es sonst nur bei Pointern die typischerweise speziell gekennzeichnet und behandelt werden (und natürlich ähnlich aber nicht so unübersichtlich bei globalen Variablen). Standardobjekte (wie arrays) zeigen typischerweise immer auf einen eigenen Speicherplatz (jedenfalls soweit der Programmierer das bei Kopiervorgängen usw mitbekommt).

Was ich sagen will ist, dass Datenkapselung vermutlich DAS wichtigste Konzept neben der Vermeidung von GOTO usw ist um ein strukturiertes, wartbares und fehlerfreies Programm zu erstellen. Und dieses Konzept wird in modernen Programmiersprachen mit Füßen getreten und Kritik wird hier mit der Begründung abgetan: Das machen doch fast alle "modernen" Programmiersprachen so. Naja. --(nicht signierter Beitrag von 92.228.95.17 (Diskussion) 23:52, 5. Feb. 2018 (CET))

Skriptsprache?

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))

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)

Ä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)

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)

"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)

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)

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)

wikidata

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)

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)

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)

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)

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

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)

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)

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

...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)

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.[[7]] «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))

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)

Groß- und Kleinschreibung

Hallo, ich habe erfahren, das Python auf Groß- und Kleinschreibung achtet. in welchem Abschnitt könnte man das erwähnen? Oder muss man dafür einen neuen Abschnitt anlegen? Liebe grüße, --Finn2431 (Diskussion) 11:02, 9. Apr. 2021 (CEST)

Das fügt sich am ehesten in den Abschnitt zur Syntax ein. Gruß Chewbacca2205 (D) 11:27, 9. Apr. 2021 (CEST)

Quicksort ist kein Quicksort...

Eigentlich muss man das an vielen Stellen in der Wikipedia korrigieren, mir ist es halt jetzt grad hier aufgefallen: Der als "Quicksort" bezeichnete Algorithmus bezeichnete funktionale Algorithmus ist nicht wirklich Quicksort, denn das wesentliche Element für die entsprechende Geschwindigkeit des Algorithmus, ist, dass die Daten im Array verbleiben und nicht neue Listen angelegt werden. --85.212.72.147 11:43, 8. Nov. 2021 (CET)

Da hat die IP prinzipiell recht. Dass keine neuen Listen angelegt werden hat zwar nichts mit der Geschwindigkeit des Algorithmus zu tun, ist aber eine prinzipielle Eigenschaft von Quicksort - siehe Quicksort#Speicherplatz. --Sebastian.Dietrich  ✉  13:24, 8. Nov. 2021 (CET)

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)

Der Python Interpreter führt keine Typprüfung durch. Daher halte ich die Aussage für korrekt. Type Hints allerdings sind ein Feature welches zunehmend Unterstützung erfährt. Allerdings ist diese Typprüfung nur für Type Checker im Rahmen des Developments gedacht. Während der Laufzeit gibt es, wie bereits erwähnt keine statische Typprüfung. --2001:9E8:6C65:B400:177B:F79D:C488:2501 19:11, 8. Mär. 2022 (CET)

.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)

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))

Zugriff auf Elemente in Closures

Die Aussage Auf diese Weise erhält man die drei Funktionsobjekte pop, push, is_empty, um den Stack zu modifizieren bzw. auf enthaltene Elemente zu prüfen, ohne l direkt modifizieren zu können. ist schlichtweg falsch. Es bedarf nur einer Python Installation um dies selbst zu verifizieren. [8]

push('Hello world')
l = pop.__closure__[1].cell_contents
print(l)
l.append(42)
print(pop())

Warum meine Änderung unter Verweis auf die Belegpflicht entfernt wurde, obgleich o.g. Falschaussage genau so wenig belegt ist, erschließt sich mir nicht. Wissenschaftliche Artikel zu diesem speziellen Feature der Programmiersprache Python sind mir nicht geläufig. --2001:16B8:6463:B600:7A1A:C2A0:31DF:FE56 00:58, 28. Feb. 2022 (CET)

Das geht schlicht und ergreifend am Thema vorbei. Python ist eine introspektive Sprache, daher kann man immer auf (fast) alle Objekte direkt zugreifen und Kapselungen umgehen; dies liegt in der Natur der Sprache. Kapselung wird nicht erzwungen (mit einer Ausnahme, aber das würde hier zu weit führen); das gilt z.B. auch für Klassen- und Instanz-Attribute, für Properties und vieles mehr. Dies wird bereits an anderer Stelle im Artikel erwähnt. Das einzige, das an dem ursprünglichen Satz verbessert werden könnte, ist das Wort „können“ durch „müssen“ zu ersetzen. --Winof (Diskussion) 16:54, 2. Mär. 2022 (CET)

Könnte man den Satz nicht einfach streichen, da er nachweislich (s.o.) sachlich falsch ist? --2001:9E8:6C65:B400:7627:EAFF:FEA9:DF7D 18:41, 8. Mär. 2022 (CET)

PS: Der geänderte Text ist sachlich nicht mehr falsch. Allerdings fehlt zu der Aussage ein Beleg. Wie belegt man die Aussage

Auf diese Weise erhält man die drei Funktionsobjekte pop, push, is_empty, um den Stack zu modifizieren bzw. auf enthaltene Elemente zu prüfen, ohne dabei auf l direkt zuzugreifen.

am besten? --2001:9E8:6C65:B400:177B:F79D:C488:2501 18:52, 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 switch in C/C++ oder case in der Bourne-Shell sind im Grunde genommen nichts weiter als ein Ersatz für if…else-Kaskaden, d.h. if-Abfragen mit mehreren Alternativen (Mehrfachverzweigung). Dagegen dient das match…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 von if…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 von switch (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. Mit match 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 das switch/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)

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 und if auf. Das stimmt so nicht bzw. es erweckt einen falschen Eindruck; man müsste mindestens auch try…except und with erwähnen, sowie das neue match…case. Natürlich sind auch Funktions- und Klassen-Definitionen „syntaktische Konstruktionen“, und dann gibt es noch Dinge wie async, 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)