Diskussion:Python (Programmiersprache)/Archiv/1

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/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Übersichtlichkeit

"Allerdings lehnen die Entwerfer von Python Perls unübersichtliche, kryptische Syntax ab und formulieren sparsamer und damit besser lesbar."

Ist das nicht eine stark wertende Aussage? Perl hat eine relativ komplexe Syntax, ist aber sicher nicht per se unübersichtlich oder kryptisch. -- Mx2000 16:46, 3. Apr 2004 (CEST)

Nun ja, das ist ein weites Feld. Perl tritt jedenfalls deutlich häufiger in der Form auf, wobei nicht eindeutig geklärt ist, ob die Sprache zu dem Stil verleitet oder Leute anzieht die gern kryptisch schreiben. -- ok ok ich stochere in einem Wespennest. Aber es wäre deutlich günstiger, den Satz so zu formulieren, daß der Schreiber keine Stellung bezieht:

"Allerdings lehnen die Entwerfer von Python Perls ihrer Ansicht nach unübersichtliche, kryptische Syntax ab und formulieren sparsamer und damit besser lesbar."

Tismer 00:48, 15. Jan. 2007 (CET)

Interaktiv

Ich fände es besser, wenn alle Punkte unter interaktiv zu den Weblinks zusammengefasst werden würden. Es würde mehr die Form des Artikels erhalten, die meiner Meinung nach sonst verloren geht. Nun doppelt bestehende Links müssen raus und die restlichen Weblinks könnte man unter sonstiges zusammenfassen. --mfg Milanx 14:39, 8. Jul 2004 (CEST)

Jupp. Finde ich auch. Bei der Gelegenheit sollten auch gleich ein paar Links ausgemistet werden und nur die wichtigsten Einstiegspunkte verlinkt werden. Das wird sonst zu unübersichtlich und man muss sich durch etliche Links klicken, ohne zu wissen, wo man nun anfangen soll. --Sprezz 15:25, 8. Jul 2004 (CEST)

Dann würde ich aber auch noch einen extra Punkt für Tutorials hinzufügen.

Hätte ich persönlich nix dagegen, aber da kommen für mich momentan nur 3-4 Seiten in Frage, die wirklich gut sind. Alle anderen enthalten nur rel. allgemeine Sachen, die IMHO in den bereits gelisteten Links besser beschrieben sind. Ich habe deswegen auch nur einen Link zur python-Website mit deutschen Dokumentationen gesetzt, da dann von "offizieller" Seite aus Seiten gelistet werden. Allerdings bin ich der Meinung, dass man da auch mal aufräumen könnte. ..--Milanx 23:11, 9. Jul 2004 (CEST)

Dann mach ma

Review II

Wiesoe ist der Artikel beim Re-Review gelandet? Sollen Neuigkeiten berücksichjtigt werden? So kanz aus dem hohlen Bauch fallen mir als erstes Unicode und Zeichenkodierungen, sowie der Stackless Fork ein. -- Pjacobi 09:43, 1. Sep 2004 (CEST)

Ich persönlich finde, dass der Artikel den Anforderungen für exzellente Artikel nicht mehr entspricht, siehe auch mein Kommentar auf der Review-Seite. Verglichen etwa mit en:Python programming language hat er sehr wenig an Information. Für nicht-programmieren-könnende Leute sollte auch etwas mehr an Information da sein (vgl. Kandidaten-Diskussion zu Legend of Zelda oder mathematische Artikel wie die Kreiszahl). Nicht zuviel, aber auch. Die Verwendung von Python kommt zu kurz, es wird nur Zope (sicher wichtig) und Mojo Nation erwähnt. U.a. entwickelt sich Python aber zur KDE-Standard-Skriptsprache. Die Community ist im wesentlichen nur in den Weblinks vorhanden, ich möchte auch irgendwie reinkriegen, dass viele ehemalige Lisp- und Smalltalk-Adapteten mit dabei sind: Die haben oft ziemlich kreative Ideen, siehe [1]. Zur Zeit sammle ich mal persönlich Material zum Verbessern des Inhalts, wenn allerdings neue und interessante Features auch hineinsollen, hab ich nichts dagegen.

Interpertiert oder Interpretierend?

Ich finde das die Änderung von "interpretiert" zu "interpretierend" falsch ist, denn nicht Python (Sprache) wird vom Python Interpreter (Programm) interpretiert, die Programmiersprache selbst interpretiert nichts, ist also auch nicht interpretierend. --Rbb 12:31, 1. Okt 2004 (CEST)

reiner werbe artikel

wieso ist der artikel mit "sehr gut" ausgezeichnet? hier werden die eigenschaften von python einseitig als gut und neu dargestellt. ich glaub nicht das jeder programmierer der meinung ist, dass das zwangseinrücken die sprache besser macht. ich hab zumindest kein bock darauf 20 zeilen quelltext um eins weiter einzurücken nur weil ich vorrübergehnt ne bedingung vorranstelle (wie ich es öffters bei fehlersuchen tue). auch das benuzen von keywords ist meiner meinung nach kein vorteil gegenüber ner symbolik. keywords machen den qelltext nur für englische programmieranfänger leichter zu lesen. für ein erfahrenen programmierer sind kurze eindeutige symbole wesentlich schneller zu ersehn. ein witz find ich eh das hier auf pythons lesbarkeit dank der keywords verwiesen wird, und dann gibt es sowas wie elif. was soll das sein, ein gut leserliches keyword? was mich aber am meisten stört sind die ständig einseitigen verweisse auf anderen programmiersprachen. achja, noch eins, python verzichtet nur auf das endsymbol eines blockes, das anfangssymbol ist ja immer durch ein doppelpunkt gegeben. ja einem doppelpunkt, keinem einrücken und auch keinem keyword sondern einem symbol! soweit zur konsequenten umsetzung der sprache.

ps:ich will hier nicht python in grund und boden reden, aber die selbstverherlichung ist nun wirklich nicht zu ertragen. python ist nicht besser und nicht schlechter als die anderen sprachen. sie hat wie alle mir bekannten sprachen (bis auf brainfuck ;) ) ihre mängel und unstimmigkeiten.

ich hab deswegen jetzt auch das exzilent durch fragwürdige neutralität ersetzt.

--SK-Genius 08:03, 9. Nov 2004 (CET)

Übrigens würde dein Text durch Einrückungen und eine korrekte Rechtschreibung (Gross/klein) auch besser lesbar. Insofern kannst du viel von Python lernen.--84.73.57.44 14:54, 1. Apr 2006 (CEST)

Deine Meinung in allen Ehren, aber die Klassifikation exzellenter Artikel ist eine community-weite Entscheidung, die durch ein Meinungsbild bestätigt werden muss. Da der Artikel inzwischen allerdings etwas verwahrlost ist, wurde er in das Review gestellt. Du kannst nicht einfach mit der Axt eigenwillig diese Art von mehrheitlichen Entscheidungen vernichten. Beteilige dich an dem Prozess, anstatt ihn zu stören.

Zur eigentlichen Aussage: Der Text erklärt doch, daß die Art der Einrückung für viele Programmierer ungewohnt und teilweise als rückständig empfunden wird. Er weist auch darauf hin, daß Probleme zwischen Tab und Space auftreten können, wenn diese nicht einheitlich benutzt werden. Ich sehe keinerlei übertriebene Werbung. Dass du keinen Bock darauf hast, zum schnellen testen einen Codeblock einzurücken, mag zwar so sein, ist aber schlechter Stil, da der Programmablauf dann nicht mehr der optischen Formatierung folgt. Bei komplexeren Arbeiten begibst du dich in die Gefahr, die vorgestellte Bedingung zu vergessen und dir seltsame Bugs einzufangen. In den meisten Projekten gilt deshalb die Konvention auch Bedingungen mit nur einer Anweisung in Blöcke zu fassen.

Ich schlage vor du änderst einfach die Teile, die dich stark stören. Gemeinsam können wir sicherlich zu einem besseren Artikel kommen.--Sprezz 13:12, 9. Nov 2004 (CET)

ok, die teile werd ich überarbeiten sobald ich zeit finde. das einrücken währe ein vorteil, wenn es automatisch von der entwicklungsumgebung anhand der symbolik (den klammern) vorgenommen würde. jedoch sollte es auch dann nicht zur syntax gehören, sondern nur zur übersicht dienen.

ich werd mich mal umschaun wo die entscheidung getroffen wird. das ist ja auf dem ersten blick nicht zu erkennen. deswegen dacht ich das man sowas wilkürlich setzten kann und es nur bestand hat wenn keiner was gegen unternimmt. halt wie's normale editieren eines artikels ganz nach dem freien wiki-prinzip. das dahinter ein "entscheidungsprozess" steht kann man ja nicht ahnen. besonders nicht bei einem wiki.

--SK-Genius 18:38, 9. Nov 2004 (CET)

Abgesehen davon, daß ich einen ganzen Absatz ohne die leiseste Bemühung um Rechtschreibung und Lesbarkeit als Zumutung empfinde und sich der Autor damit m. E. für jede Beurteilung der Lesbarkeit von Programmiersprachen disqualifiziert:

1. selbstverständlich helfen Editoren wie z.B. Vim bei der Einrückung und auch dabei, die Einrückung für ganze Codeblöcke zu erhöhen oder zu verringern
2. dadurch, daß es wenige Schlüsselwörter sind, ist die Hürde auch für Nicht-Englischsprechende sehr niedrig. "elif" läßt sich verschmerzen, existiert auch nicht nur in Python, und es erledigt gleichzeitig die Notwendigkeit einer separaten Struktur wie "case", "switch", "select" (und wie sie alle heißen)
3. was soll das überhaupt für ein Gegensatz sein - Schlüsselwörter auf der einen und kurze, schlüssige Bezeichner auf der anderen Seite? Letztlich kommt keine Programmiersprache ganz ohne Schlüsselwörter aus, wenn auch wenige damit so clever umgehen wie Rexx.
4. der Clou von Python ist gerade, daß die Einrückung signifikant ist; nur so kann eine mit der realen Ausführungslogik identische Einrückung erzwungen werden. Eine große Fangemeinde von Python findet diese Eigenschaft hervorragend und wird sie sich von niemandem madig machen lassen. Wer das nicht gut findet, läßt es eben bleiben und programmiert meinetwegen in Perl.

--Tobias 16:34, 9. Dez. 2006 (CET)

Der Mechanismus der Meinungsbildern existiert im wesentlichen an zwei Punkten: Einmal bei der Entscheidung über Löschanträge (siehe zB. hier) oder halt bei der Aufnahme von Artikeln zur Liste der exzellenten Artikel im Rahmen der sogenannten Qualitätsoffensive (weitere Informationen hier). Außerdem befindet sich der Artikel im Review, dh. auf dieser Seite sollen Verbesserungswünsche gesammelt werden. Leider liegt der Thread dort aber tatsächlich etwas brach. Insofern kann man überlegen, ob man den Artikel nicht nochmal unter den aktuellen Ansprüchen an exzellente Artikel neu prüfen lassen kann. Wie die Modalitäten dazu aussehen, kann ich allerdings nicht sagen. Vielleicht sollte man den Artikel einfach wieder neu in der Kandidatenliste (mit Verweis auf das Alter) eintragen!?--Sprezz 02:12, 10. Nov 2004 (CET)

Diskussion aus dem Review

Schöner Artikel, aber schon etwas lange auf der Liste: Seit Mai 2003, also vor der Einführung der Kandidaten-Seite. Das sieht man ihm auch an: Die Geschichte wird kaum behandelt, Anwendungsgebiete auch nicht. Der Stil hat meines erachtens auch eine Verbesserung verdient. Nachdem ich derzeit an einem Projekt mit Python arbeite, nehme ich mich des Artikels mal an, gegen weitere Verbesserungsvorschläge hab ich nichts. --nd 09:52, 30. Aug 2004 (CEST)

Ich habe vom Thema keine Ahnung, aber der erste Abschnitt zur Philosophie las sich ganz gut. Was auf jeden Fall stört ist die lange Liste von insgesamt 17 Weblinks - empfohlen werden 5. Das ist zwar nur eine Leitlinie, aber 17 sind einfach zu unübersichtlich - die kann und wird sich keiner alle ansehen wollen. Wir sind kein Webkatalog und sollte nur die besten angeben. Vielleicht kann da ein Kundiger etwas ausdünnen. --mmr 04:28, 2. Sep 2004 (CEST)

bevor der review hier anfängt vor sich hin zu schimmeln und sich irgendwo zum leben erwacht von allein entfernt. da ich bei dem thema eindeutig nicht fachkundig bin + die einwände offensichtlich nicht bearbeitet wurden - ab in 'ne neue abstimmung? -- southpark 03:49, 13. Nov 2004 (CET)

Syntaxfehler?

"Python unterstützt (und nutzt ausgiebig) die Ausnahmebehandlung als ein Mittel, um Fehlerbedingungen zu testen. Dies ist so weit in Python integriert, dass es sogar möglich ist, Syntaxfehler abzufangen."

Sollte das nicht Semantikfehler heißen? Die Berichtigung von Syntaxfehlern ist bspw. in C++ und Pascal ganz normal. Lediglich Semantikfehler kann der Compiler nicht erkennen. - MfG Viruzz (?!) 15:27, 30. Nov 2004 (CET)

Afaik nein, es ist in Python z.b. folgendes möglich:

try:
    import foo
except SyntaxError:
   print "Ein Syntaxfehler ist im Modul aufgetreten"

Wenn nun im Modul foo ein Syntaxfehler auftritt, wird auf die Exception SyntaxError reagiert. --Rbb 20:35, 30. Nov 2004 (CET)

aha ich fragte nur, weil es so als Besonderheit herausgestellt wird und ich die Syntaxüberprüfung von C++ her als ganz normal ansehe (egal in welcher Form). :) - MfG Viruzz (?!) 21:05, 30. Nov 2004 (CET)

Bei C++ kann man solche Fehler allerdings nicht mit Exception Handling zur Laufzeit abfangen. --Rbb 12:00, 1. Dez 2004 (CET)

Alles klar, danke ;) - MfG Viruzz (?!) 16:17, 1. Dez 2004 (CET)

Abfangen von Syntaxfehlern ist afaik auf Modul Import und eval/exec beschränkt. Das ist nötig, wenn man unbekannte Module laden will, aber mehr "Handling" gibt es einem nicht. Man kann z.B. nicht innerhalb von Python testen, ob eine bestimmte Syntax erlaubt ist, oder die eingesetzte Sprachversion zu jung ist. Sowas geht z.B. nicht:

try:
    def generator_example(): yield 1
except SyntaxError:
    # if SyntaxError would be raised at runtime we could do:
    # python version to low for yield keyword?
    def generator_example(): return [1]

So toll ist das mit den Syntaxfehlern also nicht und der Artikeltext verspricht zuviel. --Michael Janssen 21:34, 14. Dez. 2006 (CET)

Wenn du das machen willst musst du doch einfach nur ein kleines Wrappermodul um den Code den du testen willst schreiben.

Dass das was du da schreibst nicht geht liegt auch nicht an irgendeiner Beschränkung auf Modulimport und eval/exec, sondern einfach nur daran, dass der Interpreter das Modul erst einmal komplett parst, bevor er es auszuführen beginnt. Der Syntaxfehler fliegt dann natürlich schon beim Parsen, also lange bevor der except-Clause es abfangen kann. --moldy

---

Python (Programmiersprache), 17. November

aus der Wartung (ist bereits exzellent und steht zur Abwahl/Wiederwahl):

• Dagegen (nicht exzellent): Es fehlt Geschichte und ein Abschnitt über die Bedeutung. -- Dishayloo [ +] 00:55, 17. Nov 2004 (CET)
• abwartend fast Pro, ein gut geschriebener auch für Laien verständlicher Artikel über diese Programmiersprache, der nicht in ein HowTo abdriftet, sondern die Besonderheiten verständlich darstellt. Ein Abschnitt Geschichte fehlt sicherlich und würde mich zu einem pro bringen. --finanzer 00:09, 20. Nov 2004 (CET)
• contra: Nicht exzellent.--zeno 13:34, 20. Nov 2004 (CET)
• unentschlossen: Was wurde im Review gewartet? Bei der Menge an Typos und für den Laien unvollständlicher Formulierungen kann ich keinen Mehrwert erkennen. Schade. --Badger 19:57, 5. Dez 2004 (CET)
• contra: leider hat sich weder in der Wartung noch während diesr Abstimmung sonderlich viel getan. Für die Exzellenten reichts aus den von Dishayloo genannten Gründen IMHO nicht mehr (schade, wieder ein Informatikartikel weniger und dass, obwohl es in der WP von Informatikern nur so wimmelt >;O( -- Necrophorus 23:00, 5. Dez 2004 (CET)
• Contra siehe oben. --Bummler 09:53, 6. Dez 2004 (CET)

Ergebnis: 4 Contra, abwartend bis Pro 2

[ ""Vorschlag zu Diskussion"", dass wenn sich ein kundiger Programmierer finden lässt mann vielleicht noch eine beliebte Entwicklungsumgebung mit Angeben könnte. Fehlt! ]

Lesenswert-Diskussion

Python [ˈpaɪθn̩] ist eine objektorientierte Programmiersprache. Sie wurde Anfang der 1990er Jahre von Guido van Rossum am Centrum voor Wiskunde en Informatica in Amsterdam entwickelt, ursprünglich für das verteilte Betriebssystem Amoeba. Alle bisherigen Implementierungen der Sprache (siehe auch Jython) übersetzen den Text eines Python-Programmes transparent in einen Zwischencode, der dann von einem Interpreter ausgeführt wird.

•  Pro Antifaschist 666 00:49, 17. Okt 2005 (CEST)
•  Pro kompakt und flüssig geschrieben, lesenswert. --Heliozentrik 19:45, 20. Okt 2005 (CEST)
• Contra --Elian Φ 02:52, 21. Okt 2005 (CEST)
•  Pro - Priwo 09:07, 22. Okt 2005 (CEST)
• pro --Zahnstein 20:56, 22. Okt 2005 (CEST)

Wikibook zu Python

Täuscht der Eindruck, dass die Wikibook Baustelle relativ verwaist ist? Irgendwie tut sich da nicht mehr viel, oder?

Spricht eigentlich etwas dagegen, das OpenBook How to think like a computer scientist - Learning with Python als Wikibook ins Deutsche zu übersetzen? Das ist sicher kein Buch für alte Programmierhasen, aber für jemanden, der Python als erste Programmiersprache lernen will, ist es IMHO ganz gut. Es gibt bereits eine Übersetzung einiger Kapitel unter Wie ein Informatiker denken lernen ... mit Python, aber ich denke, wenn man sich gemeinsam daran macht, sollte es recht schnell gehen. Bei der Gelegenheit kann man die eine oder andere Anpassung z.B. bei den Variablennamen etc. machen.

Geht das? Oder muss man immer als persönlicher Autor bei einem solchen Projekt auftreten?

Wie setzt man sowas auf?

--Rat 22:26, 9. Jan 2006 (CET)

Inzwischen wurde ein Link zu "A Byte of Python" eingefügt, das ist komplett, fundiert geschrieben und gut verständlich - man sollte darauf verweisen anstelle auf der ewigen Baustelle bei den Wikibooks.

Der Link wurde anscheinend wieder entfernt (http://abop-german.berlios.de/). Warum? 217.237.151.206 15:36, 10. Dez. 2007 (CET)

Nur zur Dokumentation: Der Link ist scheinbar wieder drin. --80.136.123.130 21:43, 12. Mai 2008 (CEST)

Zu Wikibooks: Es gibt momentan drei Wikibooks über Python. Eins hat eine verwertbare Statusangabe, bei den anderen ist der Status nicht erfasst, obwohl mitunter viel brauchbares dort zu finden ist. Es gibt momentan Bestrebungen, die Bücher zusammenzuführen oder fertigzustellen, in diesem Zusammenhang würde ein Link wohl Aufmerksamkeit auf das Projekt ziehen und vielleicht neue Mitarbeiter bringen. Hier ist eine Übersicht: Python (Wikibooks). Welche Linkform wäre ggf. geeignet? Ein "Wikibooks hat auch was zu Python"-Link oder besser zu den Literaturangaben? -- 80.136.117.180 09:27, 17. Apr. 2008 (CEST)

Einen solchen Link gab es schon einmal und ich würde auch gerne wieder einen setzen, aber das geht wohl erst wieder, wenn das Wikibook fertig ist... -- WStephan 22:07, 17. Apr. 2008 (CEST)

Gegenüberstellung C und Py

Wenn ich spaß dran hab kann ich auch in C die geschweiften Klammern bei if weg lassen, sofern ich nur eine Anweisung habe. das Beispiel müsste also wie folgt lauten:

int factorial(int x)
{
  if(x == 0)
    return 1;
  else
    return x * factorial(x - 1);
}

Und somit habe ich wieder fast das selbe wie in Py.

PS: Kommentare wie diese haben in nem objektiven Artikel imho nichts verloren:

Unverbesserliche schreiben:
 int factorial(int x) { return x ? x*factorial(x-1) : 1 }

--FreaKazoid 10:17, 2. Mai 2006 (CEST)

Dass man dasselbe haben kann wie in Python, wird auch nicht in Abrede gestellt. Allerdings hat man in C (und anderen Sprachen) die Freiheit auf Einrückungen ganz zu verzichten und das Programm absichtlich (vgl. IOCCC) oder aus Nachlässigkeit unleserlich zu machen. Ich kenne Programmieranfänger, die erst programmieren und anschließend einrücken (weil der Pauker das so will). Mäkelt man den nicht eingerückten Quelltext an, hört man "Warum? geht doch auch so". Und das stimmt bei "Spielprogrammen" von 20-30 Zeilen auch. Hat man sich diesen Stil erst angewöhnt, wird man ihn hinterher schlecht wieder los. In Python muss man von Anfang an richtig einrücken, sonst funktionieren die Programme nicht. Gegängelt fühlen sich dadurch nur die Umsteiger zu Python. Wer mit Python als 1. Programmiersprache anfängt, macht es hinterher bei anderen Sprachen automatisch richtig.

Der Satz zu Unverbesserliche ... ist bereits auskommentiert, könnte man auch ganz streichen. --Rat 19:05, 2. Mai 2006 (CEST)

Das Fortlassen der geschweiften Klammern wird in den C-Syntax-basierten Sprachen oft (und nachvollziehbar, siehe unten) als schlechter Stil abgelehnt (in Java selbst so erlebt); außerdem geht es prinzipiell nur bei Einzelanweisungen, nicht bei Anweisungsblöcken. Fehler passieren gern, wenn man zunächst ohne geschweifte Klammer ausgekommen war und vergißt, sie hinzuzufügen, wenn sie durch eine hinzugekommene Anweisung nötig geworden sind... schlecht, wenn der Fehler dann wegen mangelnder Test o.ä nicht auffällt.

Ist ja verständlich, wenn C-Jünger die Syntax verteidigen, zu der sie verdammt sind; jeder glorifiziert gern sein eigenes Schicksal, das macht es erträglicher. Objektiv gibt es keinen Grund, warum die logische Struktur einmal dem Compiler und dann nochmal auf andere Weise dem Programmierer vermittelt werden sollte – mit der Gefahr der Inkonsistenz. --Tobias 12:21, 3. Aug. 2007 (CEST)

Der Artikel sollte nur die Eigenschaften von Python beschreiben und nicht wertend Programmiersprachen vergleichen. Wir sind uns doch alle einig, dass Freiheit ein hohes Gut ist, und jede und jeder kann sich die Sprache aussuchen, die ihr und ihm am besten gefaellt oder dem Problem am besten angemessen ist. (nicht signierter Beitrag von 85.214.63.253 (Diskussion) 05:51, 12. Okt. 2006)

Auch möglich ist:

factorial=lambda x:reduce(lambda a,b:a*b,range(1,x+1))

ist wesentlich kürzer

Überarbeitung Abs. Ausnahmebehandlung

Folgenden inkorrekten Satz habe ich entfernen müssen:

Es ist tatsächlich so, dass es in Python z. B. anstelle eines vorherigen Dateitestes auf Beschreibbarkeit üblich ist, die Schreibfunktion einfach auszuprobieren und eine eventuelle Ausnahme abzufangen – falls der Zugriff verwehrt wird.

Es handelt sich hierbei um keine python-spezifische Vorgehensweise, die man anwendet, weil es "üblich" ist, sondern um eine Maßnahme zur Vermeidung einer ganz bestimmten Sicherheitslücke, die situationsbedingt und nicht programmiersprachenbedingt auftritt.

Konkret sollte man keinen Zitat:"vorherigen Dateitest" durchführen, und danach anhand dieses Ergebnisses auf die Datei zugreifen, weil sich in der Zwischenzeit die Attribute der Datei geändert haben können (ermöglicht einen time-of-check-to-time-of-use exploit). vgl. den englischen Artikel en:TOCTTOU.

Nocheinmal: Das hat Null mit Python zu tun. Es ist mir ein Rätsel, wie das die Review- und Lesenswert-Diskussion überdauern konnte. --Contributor 15:10, 15. Aug 2006 (CEST)

Viele Leute vertreten die Auffassung, daß Ausnahmebehandlung nur für Ausnahmebedingungen verwendet werden sollte (daher auch der Name...). In diesem Sinne dürfte man beim Öffnen einer Datei keine Ausnahme bekommen, denn ein Fehler ist hier nichts ungewöhnliches. In dieser Denkart kann eine sichere Fehlerbehandlung (nur) mit Rückgabewerten durchgeführt werden.

Ein Grund für diese Auffassung ist, daß Ausnahmen in vielen Sprachen relativ aufwendig sind, so daß man sie aus Performancegründen vermeidet. Das ist aber in Python nicht so, und Ausnahmen werden gelegentlich bewußt auch im regulären Programmfluß verwendet, z.B. StopIteration zum Beenden eine Iteration.

Vielleicht war etwas in diesem Sinne gemeint, aber Du hast recht, so wie es dastand, war es nicht korrekt. Oefe 18:09, 15. Aug 2006 (CEST)

Doch, das ist pythonspezifisch. Das hat im Gegenteil mit TOCTTOU nichts zu tun. Man macht das in Python auch völlig unabhängig von irgendwelchen Sicherheitserwägungen. Der unter Python-Leuten oft zitierte Spruch dazu lautet "It is better to beg forgiveness than to ask for permission.". Das ist Teil einer im Pythonbereich verbreiteten Philosophie und unterscheidet sich durchaus von dem, was man in anderen Sprachen macht. Das Öffnen einer Datei ist allerdings vielleicht nicht gerade das beste Beispiel dafür. In Python wird von sehr vielen zum Beispiel auch das hier bevorzugt:

try:
    x = foo.bar
except AttributeError:
    print "foo hat kein bar!"

An Stelle von:

if hasattr(foo, 'bar'):
    x = foo.bar
else:
    print "foo hat kein bar!"
   

--moldy

Name

Bevor das gleich jemand revertet: Pyython ist nach Monty Python bennant, nicht nach dem Tier. Dazu ein Zitat aus der Orginaldokumentation (Tutorial, Kapitel 1): By the way, the language is named after the BBC show “Monty Python’s Flying Circus” and has nothing to do with nasty reptiles. Making references to Monty Python skits in documentation is not only allowed, it is encouraged! Siehe auch Monty_Python#Trivia

Lustig :-) genau das wollte ich auch gerade ändern. Vielleicht sollte man die Quelle http://www.python.org/doc/faq/general/#why-is-it-called-python angeben. --Andreas86 22:49, 26. Aug 2006 (CEST)

Daran das in der FAQ nachzuschauen hatte ich gar nicht gedacht, ich hatte mich beim lesen des Artikels nur an das Tutorial erinnert :-) Hab beide Links als Einzelquellenangbe hinzugefügt

Noch lustiger ist allerdings, das derjenige, der das vorher geändert hat, dies mit dem Hinweis "Vandalismus" getan hat. Merkwürdige Leute gibts -- Fkoch 23:15, 26. Aug 2006 (CEST) (wie auch die beiden vorangehenden, unsignierten Beiträge)

Habe ich auch erst hier in der Wikipedia erfahren, da ja wohl fast alle Sites & Bücher über "Python" mit irgendeiner Gattung oder Zeichnung der gleichnamigen Schlange verziert sind... und das Logo/Icon von "Python" zeigt zu allem Überfluss auch zwei ineinandergewundene, wenn auch sehr stark stilisierte, Schlangen! Warum dann aber die sehr interessante & wunderschöne Gattung der Pytonschlangen im Tutorial unbedingt als "nasty" verunglimpft werden muss...?? --Kuddel 21:28, 18. Apr. 2008 (CEST)

Kategorie

Python ist eine Programmiersprache. Daß sie auch eine Skriptsprache ist, mag sein, ich denke aber eher, daß Bash-Skripte in diese Kategorie gehören, nicht vollwertige Programmiersprachen. Ich möchte, daß Python in die Kategorie Programmiersprachen aufgenommen wird. Das habe ich selbst auch schon gemacht, allerdings wurde dieser Edit revertiert. --Gnushi 15:13, 12. Dez. 2006 (CET)

Der Begriff der Skriptsprache ist klar definiert und umfaßt mitnichten nur Shell-Skripten. Zudem (bzw. genau aus diesem Grund) ist die Kategorie „Skriptsprache“ bereits eine Unterkategorie von „Programmiersprache“. – Holger Thölking (d·b) 15:53, 12. Dez. 2006 (CET)

Python ist auch eine objektorientierte Programmiersprache. Deshalb ab mit dem Artikel in objektorientierte Programmiersprachen Kategorie!

lambda

Das Schlüsselwort lamda (oder so) wird zwar erwähnt und es wird ein Vergleich zu funktionalen Sprachen, aber es wird überhaupt nicht erklärt. (Zumindestens eine grobe Andeutung wäre hier wohl sinnvoll.)

Es gibt inzwischen einen (auch verlinkten) Artikel lambda-Funktion (Python). --Tobias 12:35, 3. Aug. 2007 (CEST)

Schade, dass genau dieser Artikel wieder gelöscht wurde. Ich finde den Artikel für relevant in einer Enzyklopädie.

---

wiiki links zu C und Perl

Python wurde beeinflußt durch ?

Beim Lesen dieses Artikels fiel mir das Kästchen auf, worin u.a. die Sprachen gelistet werden, die es beeinflußt haben. Das sieht mir etwas geraten aus, es ist wohl eine (unvollständige) Liste von Sprachen, die Ähnlichkeiten aufweisen, aber dann würde ich es auch so nennen. Meines Wissens hat Guido z.B. keine Ahnung von Modula 3. Aber vielleicht frage ich ihn mal explizit auf PyCon 2007.

Auf jeden Fall fehlt hier ganz eklatant Algol 60, das weiß ich sicher, denn damit hat Guido angefangen, und daher stammen die Konstrukte wie a < b < c sowie multiple assignment.

Tismer 00:40, 15. Jan. 2007 (CET)

http://www.python.org/infogami-faq/general/why-was-python-created-in-the-first-place/

Guido hat sehrwohl Ahnung von Modula-3, da brauchst du ihn nicht fragen ;-)

Nur noch ein kleiner Hinweis warum das zwangseinrücken, das einige anscheiened nicht mögen, seine Vorteile hat:

Wenn ich in C folgendes programm schreibe

if(e1)
  if(e2)
    f1()
else
  f2()

könnte man meinen f2 wird ausgewertet wenn e1 nicht wahr ist. Bei Python wäre das der Fall. In C ist dieses Problem als dangling-else Problem bekannt. Weil es keine eindeutige Grammatik dafür gibt wird einfach das else zum letzten if angehängt.

erscheinungsjahr

hallo, in der englishcen wikipedia steht in den ersten sätzen 1991, hier steht 1990 Dktz 23:01, 17. Apr. 2007 (CEST)

Ist das mit der funktionalen Programmierung sicher? Sollte es nicht prozedurale Programmierung heißen?

Zwischen prozeduraler und funktionaler Programmierung besteht nämlich ein großer Unterschied! Und meiner Meinung nach, ist Python eine prozedurale und keine funktionale Programmiersprache.

Das ist immer so eine Sache, die meisten Sprachen geben an, dass sie auch mit einem funktionalen Programmierstil klarkommen, meinen dann aber eher, dass es Funktionen und Rekursionen gibt. Python enthält allerdings ein eingeschräntes lambda und ein curry-prinzip.--vicbrother 17:35, 6. Jul. 2007 (CEST)

So, wie es in der Einleitung steht, ist vermutlich mit der "funktionalen" eher die strukturierte Programmierung gemeint. Wie die klassische strukturierte Sprache Pascal (nicht aber C) unterstützt Python die Schachtelung von Funktionen.

Vielleicht wäre es besser zu formulieren:

Python ist eine imperative Programmiersprache mit einigen Merkmalen der funktionalen Programmierung, die das strukturelle, objektorientierte und aspektorientierte Programmierparadigma unterstützt.

(wobei ich das mit der Aspektorientierung gern noch etwas ausführlicher hätte; wird ein bestimmtes Modul verwendet? Dazu hätte ich gern ein Beispiel) --Tobias 11:56, 3. Aug. 2007 (CEST)

Unterschiede zu anderen Sprachen

Ein unterschied zu anderen Sprachen dürfe sein, dass Funktionen mehr als einen Rückgabewert (also ohne Tricks) haben dürfen. --vicbrother 17:35, 6. Jul. 2007 (CEST)

Nun ja, dann wird implizit ein Tupel zurückgegeben... so würde ich das also nicht ausdrücken. --Tobias 11:58, 3. Aug. 2007 (CEST)

Sprache des Pythoninterpreters

In welcher Sprache ist denn der Pythoninterpreter programmiert? Der von Perl und Lua ist ja z. B. in C geschrieben. --85.179.62.146 13:09, 5. Sep. 2007 (CEST)

Die englische Wikipedia sagt C [2] --Andreas86 20:23, 5. Sep. 2007 (CEST)

Python 3.0

Pokernikus schreibt:

Python 3.0 wird bei der Sprache weitgehend identisch bleiben, jedoch durch interne Änderungen inkompatibel zu Python 2.0 sein.

Klingt für mich widersprüchlich, was ist hier gemeint? --Herbert Klaeren 09:54, 3. Okt. 2008 (CEST)

Hab mal versucht den Widerspruch anhand des Aritkels auf heise online aufzulösen. --aWak3N ^?!? 13:10, 4. Okt. 2008 (CEST)

Sollten wir den Artikel nicht langsam mal umstellen auf Python 3.0 oder ist das noch zu früh? Z.B. sollten die print Befehle in Print() umgewandelt werden, aber derzeit (und noch für lange Zeit) ist Python 2.6 weit verbreitet. --Svenstaro 03:45, 22. Dez. 2008 (CET)

Neutralität?

Hallo. Der Python-Artikel liest sich wie eine Reklamebroschüre. Er verstößt damit gegen den Grundsatz der Neutralität. Mehrmals wird betont, wie grossartig Python ist. Im gesamten Artikel steht nicht eine einzige kritische Bemerkung über Python. Hier ein paar Kostproben:

Python wurde mit dem Ziel entworfen, möglichst einfach und übersichtlich zu sein. Dies wird durch zwei Dinge
erreicht: Zum einen enthält die Sprache einen sehr mächtigen Funktionsumfang in nur wenigen Schlüsselwörtern, zum
anderen wurde die Syntax reduziert und auf Übersichtlichkeit optimiert. Dies führt dazu, dass Python eine Sprache
ist, in der man schnell, einfach und leicht programmieren kann. Sie ist daher besonders dort geeignet, wo
Übersichtlichkeit und Lesbarkeit des Codes eine herausragende Rolle spielen – z. B. in der Teamarbeit, bei
Beschäftigung mit dem Quellcode nach längeren Pausen oder bei Programmieranfängern.

Dass das Ziel erreicht wurde, ist eine persönliche Einschätzung des Autors. Andere sind da vielleicht ganz anderer Meinung. Dass man mit Python schnell, einfach und leicht programmieren kann, ist eine Meinung, die nicht von allen Programmierern geteilt wird. Es gibt übrigens auch andere Programmiersprachen, die mit dem selben Anspruch auftreten. Da könnte man differenzieren.

Python ist eine Sprache, die den Programmierer nicht zu einem einzigen bestimmten Programmierstil zwingt.

Das ist eine Interpretation. Schreib einfach hin, was Python tut und was nicht. Wir, die Leser entscheiden dann, ob Python zu einem Stil zwingt oder nicht.

Industrial Light & Magic setzt Python erfolgreich für seine Arbeitsabläufe ein.

Ob der Einsatz erfolgreich ist, ist ein Urteil, das der Leser sich selber bilden möchte. Grundlage dieses Werturteils?

Python besitzt eine größere Anzahl von grundlegenden Datentypen.

Welche denn? Ob es sich um eine größere Anzahl handelt, kann der Leser dann selber entscheiden.

Der Abschnitt Syntax suggeriert, dass es in Python keine Schlüsselwörter ausser den genannten gibt. Weiter unten kommen aber def, return und so weiter. Warum kann man nicht einfach sagen, wieviele Schüsselwörter es sind? Ob es viele oder wenige sind, kann der Leser dann selber entscheiden.

Dadurch tritt das Dangling Else-Problem bei Python nicht auf. Es ist jedoch darauf zu achten, die Einrückungen im
gesamten Programmtext gleich zu gestalten. Die gemischte Verwendung von Leerzeichen und Tabulatorzeichen kann zu
Einrückungen führen, die nicht der Blockstruktur entsprechen. Der Python-Interpreter geht davon aus, dass ein
Tabulator-Zeichen genau acht Leerzeichen entspricht, auch wenn der Editor einen Tabulator in der Breite von z. B.
vier einfachen Leerzeichen darstellt.

Mit anderen Worten: Das Dangling-Else-Problem tritt in Python doch auf. Der Absatz liest sich so, als ob der Programmierer schuld daran ist, wenn die Einrückungen falsch herauskommen.

Dies ist so weit in Python integriert, dass es sogar möglich ist, Syntaxfehler abzufangen und zur Laufzeit zu
behandeln.

Das klingt ganz so, als ob es etwas Gutes wäre. Darüber kann man aber streiten.

Ausnahmen haben einige Vorteile gegenüber anderen beim Programmieren üblichen Verfahren der Fehlerbehandlung. Sie
sind Thread-sicher und können leicht bis in die höchste Programmebene weitergegeben werden, oder an einer
beliebigen anderen Ebene der Funktionsaufruffolge behandelt werden. Der korrekte Einsatz von Ausnahmebehandlungen
beim Zugriff auf dynamische Ressourcen erleichtert es zudem, bestimmte auf Race Conditions basierende
Sicherheitslücken zu vermeiden, die entstehen können, wenn Zugriffe auf bereits veralteten Statusabfragen basieren.

Welche anderen Verfahren sind gemeint?

wenn man sich die erwähnten Nachteile anschaut, wohl Returncodes und gobale Statusvariablen (ERRNO). Ergänzt. Oefe 20:11, 28. Jun. 2008 (CEST)

Ausnahmen und deren Behandlung stellen einen grundlegenden Programmierstil dar. Sie führen dazu, dass der Code zur
Fehlerbehandlung nicht mit dem eigentlichen Programmcode vermischt ist, wie das oft in Programmiersprachen ohne
eigene Ausnahmebehandlung (z. B. C) beim Test von Rückgabewerten, typischerweise auf − 1, der
Ganzzahl-Repräsentation für einen Fehler, zwangsläufig geschieht.

C als Strohmann, den man verbrennen kann.

Nein, C als eine weit verbreitete Sprache, die keine Exceptions unterstützt, und stattdessen auf Returncodes und gobale Statusvariablen setzt. Die meisten anderen verbreiteten modernen Sprachen unterstützen ja Exceptions. Insofern stellt sich die Frage, ob man den Absatz nicht etwas zusammenstreichen und sich auf Python-spezifisches beschränken sollte.Oefe 20:11, 28. Jun. 2008 (CEST)

Python verfügt über eine große Standardbibliothek, wodurch es sich für viele Anwendungen gut eignet.

Wie groß? Ob sich Python gut eignet, ist ein Urteil, das sich der Leser selber bilden möchte.

Ein Beispiel für die gute Lesbarkeit und die Kompaktheit von Python-Code, hier anhand des Quicksort-Algorithmus:

Ich halte das Beispiel für schlecht lesbar. Der Autor wohl auch, denn er hat ja versucht, dem Leser mit dem Kommentar etwas zu helfen.--AlfonsGeser 19:45, 3. Jun. 2008 (CEST)

Sprachlich kann man den Artikel sicherlich entschärfen ("erfolgreich" etc. ersatzlos streichen), aber der Satz " Python ist eine Sprache, die den Programmierer nicht zu einem einzigen bestimmten Programmierstil zwingt." ist schlicht und einfach richtig. Welche Programmierstile möglich sind, sollte man wohl noch explizit hinschreiben, an der Richtigkeit des vorherigen Satzes ändert das aber nichts.

gemeint war wohl, dass Python eine Multiparadigmensprache ist, man also jeweils das geeignete Paradigma wählen kann. Habe das ergänzt.Oefe 20:11, 28. Jun. 2008 (CEST)

Zu deinem Kommentar: "Mit anderen Worten: Das Dangling-Else-Problem tritt in Python doch auf. Der Absatz liest sich so, als ob der Programmierer schuld daran ist, wenn die Einrückungen falsch herauskommen." - Nein, es tritt nicht auf und ja, es ist die Schuld des Programmierers. Wenn der Quellcode nicht konsistent ist, ist das ein Programmierfehler, da es im Falle von Python einer Verletzung der Syntax gleichkommt. In anderen Sprachen ist das anders, weil die geschweiften Klammern dort optional sind - Einrückungen (deren Breite definiert ist) sind aber genau das in Python nicht.

Dangling-Else-Problem und Einrückungsfehler sind nicht dasselbe. Ich hoffe, das ist durch den von mir eingefügten Absatzumbruch etwas klarer geworden. Zusätzlich habe ich noch ergänzt, welche Mittel Python zur Verfügung stellt, um Einrückungsfehler durch inkonsistenten Gebrauch von Tabs und Leerzeichen zu finden.Oefe 20:11, 28. Jun. 2008 (CEST)

zu "Das klingt ganz so, als ob es etwas Gutes wäre. Darüber kann man aber streiten.": Streiten kann man prinzipiell über alles - den Satz finde ich aber neutral formuliert.

zu "C als Strohmann, den man verbrennen kann.": C ist eine weit verbreitete und bekannte Sprache, in der das erwähnte Phänomen auftritt und bietet sich daher als Beispiel an. Wenn sie die Sinnhaftigkeit eines Beispiels an sich in Frage stellen, muss ich ihnen mit Verweis auf WP:OMA widersprechen.

zu "Der Abschnitt Syntax suggeriert, dass es in Python keine Schlüsselwörter ausser den genannten gibt. Weiter unten kommen aber def, return und so weiter. Warum kann man nicht einfach sagen, wieviele Schüsselwörter es sind? Ob es viele oder wenige sind, kann der Leser dann selber entscheiden.": Der Abschnitt ist unglücklich formuliert, das gebe ich gerne zu. Wie viele es sind, kann man natürlich schreiben, aber wer kann sich (siehe widerum WP:OMA) darunter etwas vorstellen? Wenn man das so macht, müsste man also auf jeden Fall wieder einen Vergleich (ja, mit dem Strohmännchen C) in den Artikel einbauen - geht aber natürlich auch. Ähnliches trifft auf ihre Bemerkung bezüglich der Standardbibliothek zu.

zu "Ich halte das Beispiel für schlecht lesbar. Der Autor wohl auch, denn er hat ja versucht, dem Leser mit dem Kommentar etwas zu helfen.": Das ist so nicht richtig, der Kommentar zeigt eine 2. Möglichkeit für dasselbe Problem auf (ist also ausführbarer Code, der dasselbe tut) und somit ein Indiz für die oben erwähnte Freiheiten die Python einem Programmierer bezüglich des Stils lässt. -- WStephan 22:38, 3. Jun. 2008 (CEST)

Ich hoffe, das ist jetzt durch die Trennung von Beispiel und imperativer Umformulierung etwas klarer. Oefe 20:11, 28. Jun. 2008 (CEST)

Ich kann mich AlfonsGeser nur anschliessen, der Artikel ist sehr euphorisch geschrieben und provoziert damit einen flame war. Da sollte mal jemand mit der Drahtbürste drüberfegen... Klaeren

Habe bislang nichts mit Python gemacht, Kritik existiert aber definitiv. In einer Vorschau zur Version 3 der Zietschrift c't (Ausgabe 21/2007) wurde angemerkt, dass die Sprache gegenüber der Konkurrenz mittlerweile zurückgefallen sei. Version 3 wurde wiederum für ihre sinnvollen Verbesserungen gelobt. Dass es da noch einiges mehr gibt, zeigt eine mal von mir auf die Schnelle durchgeführte Google-Suche - seien die Kritikpunkte nun gerechtfertigt oder nicht. --Marcus Schätzle 18:25, 4. Jun. 2008 (CEST)

Deine Google-Suche führt nur zu einigen spärlichen Ergebnissen. Suche nach Python Warts findet mehr, und fundiertere Kritik. (Der Begriff "Python Warts" wurde von A.M. Kuchling eingeführt und von vielen weiteren Kritikern übernommen.) Oefe 19:32, 26. Jun. 2008 (CEST)

Ich habe einen neuen Abschnitt "Kritik" angefangen, und einige Kritikpunkte aufgeführt. Ich werde versuchen, das in den nächsten Tagen zu erweitern -- Oefe 20:36, 26. Jun. 2008 (CEST)

Nachteile?

Da der Artikel recht einseitig aufgebaut ist (Python ist toll! Preist es!) wäre ein Abschnitt "Nachteile" gut geeignet zB

- Andere Lösungen wie in anderen Programmiersprachen, eine for schleife sieht völlig anders aus, repeat until gibt es garnicht - dann noch der ungewöhnliche Syntax

- Zeiger?

- zwingt Programmierer sich an Einrückungen zu halten

ANMERKUNG: Dass es ein Nachteil sein soll, die Syntax beachten zu müssen halte ich für seltsam...

- Erschwert Umsteigern das Programmieren in Python

- Man benötigt erst einmal einen Interpreter (auf Linux Systemem vorinstalliert, aber Windows...) compilieren ist keine lösung, dann entfallen wieder vorteile

Erwiderung: Einen Interpreter „haben zu müssen“, ist dann kein Nachteil mehr, wenn die Sprache etabliert ist und Interpreter guter Qualität für jedes relevante Betriebssystem erhältlich sind; im Gegenteil, dann kann es ein großer Vorteil werden, weil portabel geschriebene Programme dann gleich für eine Vielzahl von Plattformen zur Verfügung steht. --Tobias 12:43, 18. Aug. 2008 (CEST)

Hier ein paar subjektive Anmerkungen zu den IMHO ziemlich konstruierten obigen Punkten:

-Wieso muß eine andere Lösung ein Nachteil sein? Nur weil Du zu faul bist Dich auf was Neues einzulassen? Wenn man sich damit beschäftigt, ist die Syntax gar nicht so ungewöhnlich. An for und repeat until habe ich bisher nichts vermisst, eher schon switch.

Anmerkung: Ich finde die Lösung if... elif...else durchaus elegant. --Tobias 12:43, 18. Aug. 2008 (CEST)

-Variablen in Python sind Referenzen auf Objekte und damit eine Art Zeiger. Allerdings gibt es keine Zeigerarithmetik wie in C. Bisher habe ich sie aber auch nicht vermisst.

-Wenn man eh gewohnt ist seinen Code ordentlich einzurücken, dann fällt einem die Pflicht gar nicht auf. Nagut, sie fällt auf, wenn man mal schnell einen Block ohne den umschließenden ausführen will.

Anmerkung: Die Regel, Funktionen möglichst so kurz zu halten, daß auf eine Bildschirmseite passen, gilt eigentlich allgemein (nicht nur für Python). Ansonsten behelfe ich mir manchmal mit einer Leerzeile; diese trennt dann für meinen Vim einen Absatz ab, den ich mit { anspringen kann. --Tobias 12:43, 18. Aug. 2008 (CEST)

-Natürlich ist für einen Umstieg ein gewisser Aufwand nötig, aber das ist bei jeder Sprache so. Mehr als zum ersten Punkt ist hier nicht zu sagen.

-Dieses "Problem" hat jede Skriptsprache. Außerdem könnte man fertige Programme z. B. mit py2exe bearbeiten, dann braucht der Endanwender kein installiertes Python.

--Krille 00:25, 30. Jun. 2008 (CEST)

-subjektivität hat in der Wikipedia aber NICHTS zu suchen! Wenn es danach geht schreiben wir mal schnell den Microsoft Artikel um, weil wir die so wenig mögen!

Erwiderung: Subjektiv, das sind immer die anderen, gell? --Tobias 12:43, 18. Aug. 2008 (CEST)

-Man muss sich umgewöhnen obwohl es in jeder anderen Programmiersprachen genauso ist - nur nicht in Python? Das umdenken, besonders wenn man mit mehreren Sprachen zu tun hat, wird dadurch erheblich erschwert.

-Dann würd ich dir empfehlen mal ein wenig mit Zeigern zu spielen, das fehlt garantiert in Python.

Erwiderung: Jawohl, und zwar mit Absicht. (Die Spielerei mit Zeigern wurde in C++ gegenüber C wohlweislich stark eingeschränkt; stattdessen wurden Referenzen eingeführt, die sich nicht auf andere Adressen umbiegen lassen) Stattdessen werden veränderliche Datentypen prinzipiell per Referenz übergeben; das reicht m. E. völlig. Python ist performant genug, um beim 100-Dollar-Laptop die Basis für die Oberfläche Sugar zu bilden. --Tobias 12:43, 18. Aug. 2008 (CEST)

Man MUSS sich dran halten, und es ist nicht möglich anderes zu formatieren, selbst wenn der Text so leserlicher wär!

Erwiderung: Falsch. Der einzige bei der Einrückung kontroverse Punkt (wohin mit den Klammern?) entfällt bei Python, weil es hierfür keine Klammern gibt. Ansonsten kann jeder echte Verstoß gegen die Python-Einrückungsregeln die Lesbarkeit nur verschlechtern (ich bin schwer gespannt auf ein Gegenbeispiel), und es wird auch nicht alles vorgeschrieben: Innerhalb von Klammern (z. B. für Argumentlisten, Listen, Tupel und Dictionarys) z. B. darf umgebrochen und dann auch nach Geschmack eingerückt usw. werden. --Tobias 12:43, 18. Aug. 2008 (CEST)

Man kann nicht alles in Python schreiben, man muss auch andere Sprachen nutzen! Oder schon mal versucht einen kompletten Python Interpreter in Python zu schreiben?

Erwiderung:

1. Niemand hat gefordert, alle anderen Sprachen abzuschaffen
2. Es gibt einen in Python geschriebenen Python-Interpreter, nämlich PyPy. --Tobias 12:43, 18. Aug. 2008 (CEST)

Eventuell könnte man möglicherweiße auch vieleicht... merkst du was an deiner Argumentation? 89.49.21.21 01:58, 16. Aug. 2008 (CEST)

Ich merke insbesondere etwas an Deiner. Ansonsten solltest Du Dich mit einem Usernamen anmelden, wenn Du hier nicht nur herumtrollen willst. --Tobias 12:43, 18. Aug. 2008 (CEST)

Einsatz

Die Beschreibung des interaktiven Interpreters gehört eigentlich nicht in diesen Abschnitt und sollte woandershin verschoben werden.

Stattdessen könnte man hier ein paar Beispiele anführen, wofür Python tatsächlich eingesetzt wird. Solche gab es ja bereits im gelöschten Absatz "Obwohl Python als Skriptsprache Einfachheit betont ..." aus dem Abschnitt "Ziele".

--Krille 00:01, 30. Jun. 2008 (CEST)

Wahrheitsoperator

Es stand geschrieben: Der Operator == überprüft zwei Objekte auf Gleichheit. Andere Sprachen hingegen, überprüfen mit diesem logischen Operator auf Wahrheit. Der Operator is überprüft die tatsächliche Identität zweier Objekte. Welche anderen Sprachen sollen das sein und wie wird dieser ominöse Wahrheitsoperator angewandt? Logische Operatoren sind nach meinem Verständnis und, oder, nicht plus evtl. noch xor, implies o.ä. == ist ein Vergleichsoperator wie >, >=, < und <=. In manchen Sprachen (Basic) ist = sowohl Zuweisungs- als auch Vergleichsoperator, aber in welcher Sprache prüft man mit einem logischen Operator == auf Wahrheit? --Rat 23:07, 24. Sep. 2008 (CEST)

Hallo Rat, hast vollkommen recht, den Begriff der Wahrheit gibt es in diesem Zusammenhang gar nicht. Die Formulierung war ziemlich unglücklich. Danke fürs entdecken und verbessern! --Herbert Klaeren 09:15, 26. Sep. 2008 (CEST)

Erscheinungsjahr

Hier im Kasten steht 1990 auf der en:Python_(programming_language) 1991. Bitte nochmal gegenchecken. Danke 141.20.192.160 18:23, 24. Okt. 2008 (CEST)

1991 ist wohl eher richtig, jedenfalls wird auf http://docs.python.org/dev/3.0/license.html für die erste Release (0.9.0) als Erscheinungsjahr 1991 angegeben. Vielleicht hat jemand Python was created in the early 1990s misverstanden als wurde Anfang 1990 geschaffen. Ich korrigiere es entsprechend. Oefe 20:25, 25. Okt. 2008 (CEST)

Fehler in Codebeispiel?

Meiner Meinung und der meines Compilers nach ist das falsch:

def add_and_print_maker(x):
    def temp(y):
        print("{0} + {1} = {2}").format(x, y, x + y)
    return temp

Viel eher müsste in der dritten Zeile doch stehen:

print("{0} + {1} = {2}".format(x, y, x + y))

Oder? – Simon Diskussion/Galerie 21:50, 16. Jan. 2009 (CET)

Richtig. ".format" wird innerhalb der Print-Funktion direkt auf den String angewandt. Habe es korrigiert. --Aetas volat. 14:50, 17. Jan. 2009 (CET)

Link [16] "Python gehört zu den langsameren Programmiersprachen"

Hat sich eigentlich schon mal jemand den Link [16] "Python gehört zu den langsameren Programmiersprachen.[16] ..." durchgelesen?

Der Autor des Artikels hat sein erstes Python Programm geschrieben, und erstellt zig-tausendmal die gleiche Liste (range(KONSTANTE)). Na klar, dass das langsam ist. Das wäre in jeder Programmiersprache langsam. Außerdem ist der Artikel mehrere Jahre alt. Also ich finde die Formulierung "Python gehört zu den langsameren Programmiersprachen" unpassend. (nicht signierter Beitrag von 89.246.208.162 (Diskussion | Beiträge) 21:03, 18. Mär. 2009 (CET))

Der Link mag Mist sein (ich habe ihn nicht geprüft), aber Python gehört mit den aktuellen Implementierungen in die Liga der langsamen Sprachen, d.h. 1 bis 1.5 Größenordnungen langsamer als C++. Ich kenne die ganzen Diskussion von wegen "C wird doch auch interpretiert -- vom Prozessor nämlich" oder "IO-gebundene Programme sind in Python genauso schnell wie in C", aber man muß da einfach mal ehrlich sein. Würde man OpenOffice in Python schreiben, würde man es nicht mehr benutzen können, weil's zu langsam würde. Das ist aber nicht prinzipiell so: Theoretisch könnte ein Genie einen Python-Compiler schreiben, der in Code umsetzt, der genauso schnell wie C ist, aber das muß wohl erst noch geboren werden. – Torsten Bronger 14:57, 20. Mär. 2009 (CET)

1 bis 1,5 Größenordnungen halte ich für totalen Quatsch. Für reines number-chrunching (was der worst case wäre) liegt der Faktor bei etwa 100 (allerdings gibt es natürlich auch hier optimierte module, die sich mit der Geschwindigkeit von C messen können). Für bestimmte Bereiche (z.B. String-Verarbeitung) ist der Faktor *weit* geringer, da hier von Python im Grunde nur bereits stark optimierten (C-)Code ausgeführt. Einen richtigen Python Compiler wird es vmtl. nie geben, dazu ist die Sprache zu dynamisch (JIT_Compiler gibt es schon - nennt sich pysco). An entsprechend schnellen Interpetern wird allerdings gearbeitet (stichwort pypy, unladen swallow). Die Geschwindigkeitssache sollte man differenziert sehen. Natürlich ist der Ausdruck a+b=c für langsamer als in C. Dafür kann er auch viel mehr (z.B. beliebig große Zahlen addieren, strings aneinander heften, ...). Würde man alle Features in C umsetzten hätte man wieder die gleiche Geschwindigkeit wie in Python (natürlich braucht man nicht immer alle, deswegen ist Python bei einfachen Systemen entsprechend langsamer als C). Python profitiert also von komplexen Aufgaben und ist da auch entsprechend schnell. Die Ausführungen mit OpenOffice sind großer Quatsch. Natürlich wäre es möglich ein solches Programm auch performant in Python umzusetzen. Man muss bloß die langsamsten Teile (meistens 5% des Codes, dafür 95% des Zeitverbrauchs) entsprechend otimieren oder auslagern. --89.196.27.122 18:34, 1. Mai 2009 (CEST)

Auslagern, optimieren, "Python-Funktionen können mehr" – das ist alles richtig, aber andere Baustellen. Wenn ich einen nackten Standard-Algorithmus (z.B. Suche/Sortierung) in Python implementiere, bin ich Faktor 10 bis 30 langsamer als in C. Daß das in der Praxis in vielen Anwendungsfällen keine Rolle spielt, ist ja richtig, ich persönlich setze ja auch ausschließlich auf Python. Aber die aktuellen Python-Implementierungen führen vergleichbaren Code numal soviel langsamer aus, und das sollte man dann auch im Artikel zu schreiben. Es geht auf Wikipedia ja nicht um Werbung für Python. – Torsten Bronger 08:21, 27. Nov. 2009 (CET)

Meiner Meinung nach fehlt dem Link definitiv die Relevanz für diesen Artikel. Sicher mag Python zu den langsameren Sprachen gehören, aber die Diskussion auf dem verlinkten Blog entbehrt jeglicher Sachlichkeit. Ich bin für Entfernen. --Xjs. 19:45, 1. Jun. 2009 (CEST)

Nur weil sich der Link kritisch mit Python auseinandersetzt, ist er nicht destruktiv. Er ist m.E. fundiert und ggf. reproduzierbar. Ich verstehe nicht, warum er gelöscht werden sollte. --Bettercom 21:39, 1. Jun. 2009 (CEST)

Ich bin für eine Entfernung dieser Aussage. Solche Aussagen trifft man nur bei entsprech. Relevanz - wenn es besonders negativ/positiv im Vergleich zu gleichartigen(interpretierten) Sprachen ausfällt. Noch dazu sind die Tests sehr stark abhängig von der jeweiligen Implementierung und Version der Interpreters. --Darktrym. 21:30, 27. Nov. 2009 (CEST)

C Code

Von der Syntax her ist der C Code richtig, nur rechnet er keine Fakultät aus , sondern es wird nur eine Zahl n mit einer Zahl n-1 multipliziert.

Bsp:

Quellcode auf der Seite :

n= 4

Daweil rechnet er 4*3 = 12

wie kommst du darauf? Hast du das C-Programm mal compiliert und laufen gelassen? --Herbert Klaeren 22:17, 27. Dez. 2009 (CET)

Fakultät wäre:

4*3*2*1 = 24 (nicht signierter Beitrag von 86.33.137.93 (Diskussion | Beiträge) 14:42, 27. Dez. 2009 (CET))

ja richtig, und genau das berechnet das Programm auch. --Herbert Klaeren 22:17, 27. Dez. 2009 (CET)

Der Code ist zwar korrekt, aber nicht schön. Griffiger wäre

int fakultaet(int x) { return (x > 1 ? x * fakultaet(x - 1) : 1); }

Es ist kürzer und interessanter Weise sehr ähnlich zum Python Beispiel -- 01:30, 18. Apr. 2009 (CET) (ohne Benutzername signierter Beitrag von 188.107.65.98 (Diskussion | Beiträge) )

Worte statt Zeichen

In dem Artikel steht "Die Anweisungen benutzen häufig englische Schlüsselwörter, wo andere Sprachen Symbole einsetzen.". Kann das irgend jemand belegen? Vielleicht wären einige Beispiele ganz nett, allerdings kenne ich Python nicht wirklich. Das einzige Beispiel, das mir einfällt ist "in" in Python vs. ":" in Java. Gibt es noch weitere? (nicht signierter Beitrag von BercherP (Diskussion | Beiträge) 10:29, 19. Feb. 2010 (CET))

Es gibt z. B. noch "is": if result is False: printerror() -- Krille 21:16, 28. Feb. 2010 (CET)

Iteratoren

Es wäre gut, wenn auch noch Iteratoren/Generatoren mit in den Artikel aufgenommen werden würden. Gerade die runden zum Teil das Sprachdesign elegant ab. Beispiel für die paarweise Zusammenführung von beliebig vielen Sequenzen ohne eine weitere zu Erzeugen mit Anwendung:

def izip(*iterables):
    iterables = map(iter, iterables)
    while True:
        result = [i.next() for i in iterables]
        yield tuple(result) 
for i,j, in izip("abc",[1,2,3]):
    print i,"=",j

so unkommentiert ist dieses Codestück wertlos. Wenn es jemand in den Artikel einbaut, sollte dazu erklärt werden, was da passiert. --Herbert Klaeren 20:04, 14. Apr. 2010 (CEST)

Abschnitt Funktionales Programmieren

Der Abschnitt enthaelt viel "Anspielungen" auf funktionale Techniken und ist nur fuer FP-Freaks verstaendlich. Jemand, der sich eine Idee von Python verschaffen will, kann wenig damit anfangen. Ich bin leider kein FP-Freak, wuerde aber trotzdem gerne verstehen, was der Abschnitt mir sagen will. --Siggisiggi 17:15, 1. Apr. 2010 (CEST)

Dynamische Sprachen

Gleich am Anfang wird hier der Begriff „dynamische Sprache“ verwendet, ohne dass er erklärt wird. (Also ich weiss, was damit gemeint ist, aber ich täte mich schwer, es in diesem Zusammenhang griffig zu erklären.) Ich plädiere dafür, die Passage „wie andere dynamische Sprachen“ ersatzlos zu streichen. Protest? --Herbert Klaeren 20:06, 14. Apr. 2010 (CEST)

erledigt --Herbert Klaeren 12:03, 16. Mai 2010 (CEST)

Strukturierung durch Einrücken

Diese Beispiele der Fakultätsfunktion sind alle unsinnig, das ist garantiert nicht die Fakultätsfunktion. Die ist für negative Zahlen nämlich nicht definiert, und fak(0) ist =1, nicht =0. Ich hätts ja verbessert, aber dann entfällt der ganze Sinn der Demo von Strukturierung durch Einrückung. Wer findet ein besseres Beispiel? Hallo, Python-Freunde, ihr seid gefordert! --Herbert Klaeren 20:54, 15. Mai 2010 (CEST)

habe es edit. habe die vorh. diskussionseite nicht gesehen.

ein error für neg. zahlen oder nicht ganze Zahlen sollte es vollende

-- 89.247.197.12 21:27, 15. Mai 2010 (CEST)

-- 89.247.197.12 21:21, 15. Mai 2010 (CEST)

Die Funktionen sind sowieso nicht so toll:

>>> fakultaet(10000)

Gibt auch nicht die Fakultät aus sondern nur eine sehr lange Fehlermeldung Besser ist es da ohne Rekursion zu arbeiten.

>>> (lambda n:reduce(lambda x,y:x*y,xrange(2,n+1),1))(10000)

Dann bekommt man auch seine lange Zahl anstatt Langer Fehlermeldung --92.198.37.119 09:11, 10. Jun. 2010 (CEST)

Verbreitung und Einsatz

ein Verweis auf SAGE fehlt, sowas wie:

• Python ist die Basis von Sage_(Computeralgebrasystem) (nicht signierter Beitrag von 92.199.199.217 (Diskussion 01:46, 15. Jun. 2010 (CEST))

Linklöschung

-1: wendet sich nur an Linux-User revert, sorry, aber inwieweit ist das eine Brgeündung?--^°^ 15:31, 17. Dez. 2010 (CET)

Fragwürdige Bestandteile

"In den aktuell vorherrschenden Implementationen ist die Geschwindigkeit niedriger als bei vielen kompilierbaren Sprachen[18], aber ähnlich wie bei Perl[19], PHP[20] oder Smalltalk[20] und höher als bei Ruby.[21] Das liegt zum Teil daran, dass bei der Entwicklung von CPython Klarheit wichtiger als Performance eingestuft wird.[22] Man beruft sich dabei auf Autoritäten wie Donald Knuth und Tony Hoare, die von verfrühter Optimierung abraten."

Mag zwar stimmen, aber hat schon was von einer falschen Halbwahrheit. Python ist so langsam, weil es eine noch "höhere Sprache" ist als Java oder gar C++. Richtig ist, dass sie durch das höhere Abstaktionslevel ein besseres (klareres) Programm-Design machen lässt. Wenn das gemeint ist, sollte das im Text auch so stehen. --89.0.47.193 18:52, 26. Sep. 2010 (CEST)

Sowohl Java als auch C++ sind compilierte Sprachen, während Python interpretiert wird und deshalb (wie auch z. B. PHP und Rexx) auch zur Laufzeit generierten Code ausführen kann; dafür ist es natürlich langsamer, wenn auch nicht – wie die Formulierung „Python ist so langsam …“ fälschlich suggeriert – langsamer als andere interpretierte Sprachen. Vor der erstmaligen Ausführung wird üblicherweise eine Vorübersetzung („Objektcode“) erzeugt und abgespeichert (.pyc- und .pyo-Dateien), was die wiederholte Ausführung beschleunigt.

Wenn eine reine compilierte Sprache trotz des erzeugten Maschinencodes langsamere Programme zeitigte als eine interpretierte, würde ich mir ernste Gedanken machen. Dem Laufzeitnachteil stehen üblicherweise deutlich kürzere Entwicklungszeiten gegenüber. --Tobias 01:47, 14. Feb. 2011 (CET)