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.