Ein Kritikpunkt an Python, der in vielen Tutorials besprochen wird (siehe https://www.python-kurs.eu/python3_deep_copy.php ) 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 14:46, 21. Jan. 2018 (CET) )