Diskussion:Python (Programmiersprache)/Archiv/2

message: 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)
thread_title:  Lizenz 

message: „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)
replies: text: 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)
replies: text:  Keine dieser Sprachen taucht unter den ersten 10 und lediglich F# überhaupt im TIOBE-Index  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)

text: 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)
replies: text:  Finde ich gut so. --Mosmas 10:43, 22. Aug. 2011 (CEST)
thread_title:  Einrückung zur Blockbegrenzung 

message: * 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)
thread_title:  Galileo OpenBook 

message: 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)
thread_title:  Versionstabelle 

message: * http://blog.snaplogic.org/?p=94 (Internet Archive)
– GiftBot (Diskussion) 07:20, 5. Okt. 2012 (CEST)
replies: text: 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)
thread_title:  Defekter Weblink 

message: 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)
replies: text: Der Streit ist beendet.  --Kronf @ 01:03, 2. Mai 2013 (CEST)
thread_title:  Namensstreit 

message: 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)
replies: text: 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)
thread_title:  Box "Beeinflusst von" 

message: 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)
thread_title:  Codebeispiel Quicksort 

message: 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)
replies: text: 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)
thread_title:  Literatur 

message: 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)
replies: text: Sieht nach einem syntaktisch korrekten Satz aus. Aber es hapert an der Semantik: Ich verstehe kein Wort.  @xqt 14:52, 25. Aug. 2015 (CEST)
thread_title:  Geschwindigkeitsvergleich 

message: 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)
replies: text: 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)
thread_title:  Versionen 

message: 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)
thread_title:  Entwicklungsgeschichte 

message: 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)
replies: text: 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)
thread_title:  Ist "py" tatsächlich die drittwichtigste Sprache der Welt ? 

message: 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)
thread_title:  Literatur & Weblinks zu 3.6 

message: 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)
thread_title:  Pythons Relevanz fürs Scientific Computing 

message: Es geht um folgende Zurücksetzung von : 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
thread_title:  wikidata 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Strukturierung durch Einrücken 

message: "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)
replies: text: 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)
thread_title:  Anonyme Namensräume? 

message: 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)
replies: text: Das fügt sich am ehesten in den Abschnitt zur Syntax ein. Gruß Chewbacca2205 (D) 11:27, 9. Apr. 2021 (CEST)
thread_title:   Groß- und Kleinschreibung 

message: 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)
replies: text: 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)
thread_title:  Quicksort ist kein Quicksort... 

message: 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)
replies: text: 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)
thread_title:  Optionale statische (graduelle) Typprüfung ab Python 3.5 

message: 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)
thread_title:  .NET fehlt 

message: 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. 
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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Zugriff auf Elemente in Closures