"Alles" wieder auf null setzen

[AllesMeins]

Ich verstehe nicht, inwiefern bei dem von Dir gezeigten Code noch Zwischenergebnisse enthalten sein können?

Ich auch nicht hundert Prozent. Ein Beispiel-Falle die ich kenne wäre soetwas:

Code: Alles auswählen

class Experiment:
  data = list()

  def addData(self, item):
    self.data.append(item)

Soetwas habe ich nirgends gemacht, Tatsache ist aber das ich Python (oder meinen Python-Kenntnissen) nicht (mehr) traue und ich mir recht sicher bin, dass es dort noch einige vergleichbare Fallen gibt, die ich bisher nicht kenne. Und solche Probleme zu finden ist fast unmöglich, wenn man experimentelle Berechnungen durchführt, deren Ergebniss ich nicht kenne. Sagen wir ich würde jetzt als Experiment einfach den Mittelwert von data berechnen wollen - da würde es in dem oben beschriebenen Szenario furchtbar falsche Ergebnisse geben, aber nicht wirklich auffallen wenn die Ausgangsdaten ausreichend unbekannt sind. Und um da absolut auf Nummer sicher zu gehen will ich einfach den "kompletten" Speicher von Python löschen. Und das mache ich jetzt extern, da es intern scheinbar nicht geht.

[Hyperion]

Ah, ok. Naja, den Unterschied zwischen Klassen- und Objektattributen sollte man schon kennen - tust Du ja offensichtlich auch. Mir fallen da jetzt spontan keine anderen Szenarien ein, bei denen (autonome) Objekte automatisch bestehende Objekte angeflantscht bekommen.

Sofern Du die neu erstellten Objekte nicht in eine "Umgebung" schmeißt, die für solche Effekte sorgt, kann da nix passieren. Und solche Sachen sollten imho dokumentiert sein.

Wenn Du Dir unsicher bist, dann könntest Du doch einfach mal Tests fahren, die einmal in einer "Schleife" Experimente berechnen und diese mit manuell gestarteten Tests bzw. deren Ergebnissen vergleichen. Wenn diese identisch sind, treten wohl keine Nebeneffekte auf.

[Leonidas]

Soetwas habe ich nirgends gemacht, Tatsache ist aber das ich Python (oder meinen Python-Kenntnissen) nicht (mehr) traue und ich mir recht sicher bin, dass es dort noch einige vergleichbare Fallen gibt, die ich bisher nicht kenne.

Naja, schlecter Code der den globalen State modifiziert ist eben das - schlecht. Das hast du ja in jeder anderen Sprache auch. Und ja, ich hatte auch mal so einen Fall dass eine "Library" nur einen Aufruf zugelassen hat weil danach der State der Objekte so kaputt war dass es nicht mehr funktioniert hat. Da hab ich nach einigem fluchen später ``multiprocessing`` verwendet.

[AllesMeins]

Naja, schlecter Code der den globalen State modifiziert ist eben das - schlecht. Das hast du ja in jeder anderen Sprache auch.

Das bestreite ich ja auch gar nicht. Meine Erfahrung ist nur, dass man den globalen State in Python leichter unabsichtlich modifiziert als in anderen Sprachen. Da muss man dann ja meistens ein global davor setzen oder irgendwie anders explizit ausdrücken, dass irgend eine Variable global verarbeitet werden soll.

[lunar]

@AllesMeins: Im obigen Beispiel zeigst Du ein Klassenattribut, und wunderst Dich, dass sich dieses Klassenattribut auch tatsächlich wie ein Klassenattribut verhält, sprich zwischen Klassenexemplaren geteilt wird, und führst es als Beleg dafür an, dass man den globalen Zustand leicht unabsichtlich modifizieren könne.

Allerdings weiß jeder halbwegs erfahrene Python-Programmierer, wie sich der Quelltext im Beispiel verhalten würde, und würde sowas mithin auch nicht schreiben, ohne die Konsequenzen zu kennen. Daher ist das Beispiel auch praxisfern, denn kein Python-Programmierer würde veränderliche Objekte im Namensraum der Klasse deklarieren, wenn nicht explizit gewollt ist, dass das Objekt zwischen Exemplaren der Klasse geteilt wird (was allerdings ziemlich schlechter Stil wäre). „Unabsichtlich“ ist der Effekt des gezeigten Beispiels mithin nur und ausschließlich dann, wenn man Python nicht beherrscht.

[AllesMeins]

Das bestreite ich ja auch nicht, dass einem erfahrenen Python-Programmierer das nicht passiert. Aber darum geht es ja auch nicht, denn ob du es glaubst oder nicht - es gibt auch weniger erfahrene (Python-)Programmierer. Und dort können halt solche Fehler passieren, da Python hier Sprach-Konstrukte verwendet die durchaus auch in anderen Sprachen üblich sind, sich aber fundamental anders verhält als die meisten Sprachen. Das ist als würde Opel Autos bauen bei denen Gas und Bremse vertauscht sind und damit argumentieren das erfahrene Opel-Fahrer damit zurecht kommen.
Natürlich ist das so, keine Frage. Aber wenn man schon ne Sprache hat, die sich an einigen Stellen ungewöhnlich verhält, dann sollte man sich auch damit abfinden das es immer wieder Leute geben wird die damit (am Anfang) nicht so gut zurecht kommen. Und da ist es keine Lösung darauf zu verweisen, dass so etwas erfahrenen Programmierern nicht passieren würde. Das gilt auch für die schlechteste Sprache der Welt, dass erfahrene Programmierer damit zurecht kommen. Das ist aber kein Kriterium, das liegt in der Natur der Erfahrung - das Kriterium muss immer sein wie gut weniger erfahrene Menschen damit zurecht kommen. Und mit einem "wieso sollte das ein Problem sein, jemand der schon ewig damit arbeitet kommt doch damit zu recht" zu argumentieren ist meiner Meinung nach schlicht und einfach Blödsinn...

[Leonidas]

Also dein Beispiel ist in anderen Sprachen doch genauso "kaputt", da macht doch Python jetzt nichts speziell "falsch" sondern eher "wie halt alle anderen".

[lunar]

@AllesMeins: Das Verhalten ist nur dann ungewöhnlich, wenn man die Erfahrungen aus anderen Sprachen, insbesondere das aus Java oder C#, auf Python anzuwenden sucht. Es ist wohl offensichtlich, dass das nicht funktionieren kann. Python ist eben nicht Java. Wohl dem, der das von vorne herein begreift. Ansonsten ist man – mit Verlaub – selbst schuld, wenn Programme dann nicht so funktionieren wie gewünscht.

Es ist halt so: Entweder programmierst Du in einer Sprache, die Du beherrscht und in der Du Erfahrungen gesammelt hast (in diesem Fall wohl Java). Dann kannst Du Deine Erfahrungen und Kenntnisse direkt anwenden. Oder Du programmierst eben in einer anderen Sprache, die Du nicht beherrscht, und in der Du keine Erfahrungen gesammelt hast. Dann sind die Erfahrungen und Kenntnisse aus Java größtenteils hinfällig, und Du musst diese andere Sprache erlernen, bis Du darin wiederum ausreichend Kenntnisse und Erfahrungen erworben hast.

Andere Alternativen gibt es nicht.

[BlackJack]

@AllesMeins: Auch einem unerfahrenen Python-Programmierer passiert das nicht, sofern er sich denn die Grundlagen aneignet. Das sind ja in der Regel keine Sachen wofür man langjähriger Spezialexperte sein muss, sondern wo es reicht die Grundlagen von Python zu lernen. *Das* muss man dann aber auch bereit sein zu tun. Von einer Programmiersprache auf eine andere zu wechseln heisst eben nicht nur zu schauen wo man jetzt das Semikolon hinsetzen muss und versuchen syntaktisch ähnlichen Quelltext zu schreiben und zu hoffen, dass sich das dann schon wie gewünscht/gewohnt verhalten wird.

*Jede* Programmiersprache verhält sich an einigen Stellen ”ungewöhnlich” wenn man überall das angeblich ”übliche” Verhalten erwartet. Wenn es keine Lösung ist darauf zu verweisen, dass man die Sprache dann halt mal lernen sollte, was wäre denn dann eine Lösung!?

[sparrow]

Hmm... also hier fehlt ja komplett Code vom Threadstarter. Ich kann nur schwer nachvollziehen was überhaupt das Problem ist. Ich lese den ersten Post eher so als ob hier ein Problem mit dem "self." in Klassen auftritt.
Das es irgendwie "miteinander kommunizierende Variablen zwischen Klassen gibt" kenne ich nur von statischen Variablen.
@AllesMeins: Kann es sein, dass du die entsprechenden Variablen nicht per self gekennzeichnet hast und der Interpreter sie dhaer für Klassenvariablen hält?

Code: Alles auswählen

>>> class Testklasse:
	a = "foo" # kein self. -> Klassenvariable!
	def __init__(self, b):
		self.b = b
	def print_it_baby(self):
		print "a:", self.a
		print "b:", self.b

		
>>> fu = Testklasse("Kruemel")
>>> ara = Testklasse("Monster")
>>> uta = Testklasse("Kermit")
>>> fu.print_it_baby()
a: foo
b: Kruemel
>>> ara.print_it_baby()
a: foo
b: Monster
>>> uta.print_it_baby()
a: foo
b: Kermit
>>> Testklasse.a = "bar"
>>> ara.a = "nihil"
>>> ara.b = "Bibo"
>>> uta.b = "Samson"
>>> fu.print_it_baby()
a: bar
b: Kruemel
>>> ara.print_it_baby()
a: nihil
b: Bibo
>>> uta.print_it_baby()
a: bar
b: Samson
>>> 

Edit: Ah shit, wer die 2. Seite des Threads liest ist deutlich im Vorteil!

[snafu]

@sparrow: `self` ist nicht wirklich eine Kennzeichnung. Es repräsentiert lediglich das Exemplar der Klasse, welches in jeder Methode als erstes Argument mitgegeben wird. Du könntest stattdessen auch `this` schreiben. `self` als Name ist einfach nur eine Konvention. Was aber stimmt, ist natürlich, dass es einen Unterschied macht, ob man ein Attribut für die Klasse oder für das Exemplar erstellt.