Diskussion:Python (Programmiersprache)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Archivübersicht Archiv
Wie wird ein Archiv angelegt?

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Python (Programmiersprache)“ zu besprechen.

Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit Signatur und Zeitstempel oder --~~~~.

Hinweise

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

Defekte Weblinks[Quelltext bearbeiten]

GiftBot (Diskussion) 16:07, 26. Nov. 2015 (CET)

deepcopy-Problematik[Quelltext bearbeiten]

Ein Kritikpunkt an Python, der in vielen Tutorials besprochen wird (siehe [[1]] ) 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 [[2]] ) 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 [[3]]. 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 [[4]].

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?[Quelltext bearbeiten]

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)