Code: Alles auswählen
class A():
def __init__(self):
self.value = "a"
def change(self, other):
other.value = "b"Code: Alles auswählen
>>> a = A()
>>> b = A()
>>> a.change(b)
>>> b.value
'b'
Nein!, Es sind NIE Kopien, wenn du nicht explizit nach einer fragst ('immutable' Objekte - z.B. int, str, tuple - machen die Sache für Anfänger aber nicht unbedingt durchschaubarer).Normalerweise übergibt man doch keine Referenz auf ein Objekt oder so, sondern eine Kopie.
Quatsch. Andersrum. Auch schon in Python 2.xNocta hat geschrieben:Normalerweise übergibt man doch keine Referenz auf ein Objekt oder so, sondern eine Kopie.
Mir ist schon klar, dass er b kennt, bzw auf b zugreifen kann. Und other logischerweise gleich b ist. Nur weiß ich nicht, warum.Du kannst ja in A.change() mal ein "print( other is b)" einbauen.
Bei normalen Funktionen klappt das doch nicht, oder? Zeig mir am besten mal ein Beispiel außerhalb von OOP, ich versteh glaube nicht ganz, was du meinst.Das hat nichts mit OOP zu tun, sondern mit dem Aufrufverhalten bei Funktionen.
Du liegst komplett falsch. Die Annahmen gelten nur fuer unveraenderliche Werte, die man neu zuweisen muss, um sie zu aendern. Vereinfacht gesagt: Objekte kann man immer veraendern (und sie bleiben es), jedoch nicht den Namen wechseln (in einem ausseren Scope).Nocta hat geschrieben:Ich bin nur dadurch etwas verwirrt, weil ja eigentlich gilt, dass in Funktionen ein eigener abgeschlossener Namensraum existiert und die einzige "Schnittstelle" nach Außen die return Anweisung ist, bzw eine globale Variable.
Eine normale Funktion ändert ja auch nicht die Werte auf Modulebene, nur weil man ihn als Argument bekommen hat. Er wird doch kopiert? Lieg ich da jetzt total falsch? Hilfe
Weil die Referenz zu `b` in den lokalen Scope der Funktion kopiert wird.Nocta hat geschrieben:Mir ist schon klar, dass er b kennt, bzw auf b zugreifen kann. Und other logischerweise gleich b ist. Nur weiß ich nicht, warum.
Doch das tut es. Eine Methode ist nichts anderes als eine Funktion. `a` kennt `b`, weil du `a` mit einer Referenz auf `b` versorgst.Nocta hat geschrieben:Sorry, falls das irgendwie total bescheuert rüberkommt, aber ich verstehe immer noch nicht, warum das Exemplar a über das Exemplar b bescheid weiß.
Ich hab das bisher immer als gegeben betrachtet und mich nie gefragt, wieso.
Bei normalen Funktionen klappt das doch nicht, oder? Zeig mir am besten mal ein Beispiel außerhalb von OOP, ich versteh glaube nicht ganz, was du meinst.
Code: Alles auswählen
In [1]: a = [1,2]
In [2]: def do_foo(x):
...: x.append(42)
...: return x
...:
In [3]: b = do_foo(a)
In [4]: a
Out[4]: [1, 2, 42]
In [5]: b
Out[5]: [1, 2, 42]
In [6]: b is a
Out[6]: TrueCode: Alles auswählen
In [17]: def do_foo():
....: x = 1
....: print x
....:
....:
In [18]: x = "abc"
In [19]: do_foo()
1
In [20]: print x
-------> print(x)
abc
Du meinst so was?Nocta hat geschrieben:Ich bin nur dadurch etwas verwirrt, weil ja eigentlich gilt, dass in Funktionen ein eigener abgeschlossener Namensraum existiert und die einzige "Schnittstelle" nach Außen die return Anweisung ist, bzw eine globale Variable.
Eine normale Funktion ändert ja auch nicht die Werte auf Modulebene, nur weil man ihn als Argument bekommen hat. Er wird doch kopiert? Lieg ich da jetzt total falsch? Hilfe
Code: Alles auswählen
In [1]: a = 4
In [2]: def foo(bar):
...: bar += 1
...:
...:
In [3]: foo(a)
In [4]: a
Out[4]: 4
Code: Alles auswählen
In [5]: a = [42]
In [6]: def foo(bar):
...: bar.append(69)
...:
...:
In [7]: foo(a)
In [8]: a
Out[8]: [42, 69]
Ja, ich denke, "so was" meint er. Noch als Ergänzung:Hyperion hat geschrieben:Du meinst so was?
Code: Alles auswählen
>>> a = [42]
>>> def foo():
... a[0] = 43
...
>>> a
[42]
>>> foo()
>>> a
[43]
>>> a = [42]
>>> def foo():
... a = [43]
...
>>> a
[42]
>>> foo()
>>> a
[42]Ja. Das Verhalten ist bei Immutables dasselbe, allerdings kann man die nicht veraendern, also tritt das Problem nicht auf.Nocta hat geschrieben:Hm, bisher hab ich das mit den immutable und mutable Datentypen immer mehr oder weniger ignoriert ...
Aber das ist, wenn ich das richtig verstehe, des Rätsels Lösung?
Nein, auch hier wird die Referenz kopiert, das Verhalten ist exakt gleich.Nocta hat geschrieben:Bei immutable Datentypen wird also wirklich eine Kopie erstellt aber ansonsten wird eine Referenz übergeben?
Nur weil es andere Sprachen so machen, muss Python da nicht nachziehen, allerdings folgen viele Sprachen auch dem Weg, den Python geht. Man koennte natuerlich Syntax fuer das Uebergeben einer Kopie des Objekts einfuehren, allerdings steht man dann evtl vor demselben Problem, das bspw. C++ hat und ein explizites Kopieren folgt dem Zen von Python und macht die Absicht deutlicher.Nocta hat geschrieben:Und wie bewertet ihr persönlich das ganze Verhalten? Logisch und konsequent und vielleicht auch praktisch, oder fändet ihr es besser, wenn man Referenzen immer explizit angeben müsste, anstatt, dass hier solche Verwirrungen entstehen? So wie das in anderen Sprachen gehandhabt wird, so weit ich da informiert bin.
Perl handhabt das genau so: Es wird streng unterschieden zwischen Referenz und Wert, mit der Folge, dass man explizit derefernzieren muss, dort wo es nötig ist. Viele Neulinge streichen beim Thema Referenzen in Perl schnell die Segel - zumal die Dereferenzierung in Perl auch noch kontextabhängig ist, also z.B. zwischen Skalarem und Listen-Kontext unterschieden wird. Python arbeitet die meiste Zeit auch mit Referenzen, versteckt das aber sehr gut durch die automatische Dereferenzierung. In den meisten Fällen funktioniert das so auch völlig schmerzfrei, außer z.B. wenn man die Kopie einer Liste an eine Funktion übergeben möchte - dann muss man das per [:] machen, sonst hat die Funktion u.U. ungewünschte Seiteneffekte.Nocta hat geschrieben:(...) oder fändet ihr es besser, wenn man Referenzen immer explizit angeben müsste, anstatt, dass hier solche Verwirrungen entstehen? So wie das in anderen Sprachen gehandhabt wird, so weit ich da informiert bin.
Beispielsweise indem du alle Schreibzugriffe abfängst ( mit __setattr__).Nocta hat geschrieben:Wie schafft man es dann, dass ein selbstdefinierter Datentyp immutable wird?
Nein. Namen (in einem bestimmten Namensraum, also zb dem globalen, oder dem lokalen einer gerade ausgeführten Funktion) sind einfach Bindungen an ein beliebiges Objekt. Und da in Python alles ein Objekt ist, kann man im Grunde alles an einen Namen binden. Und das ist alles. Objekte kennen ihre Namen nicht! Die Namen sind den Objekten somit herzlich egal - ob sie an einen Namen gebunden sind oder zb in einer Liste existieren, spielt absolut keine Rolle für sie.Aber das ist, wenn ich das richtig verstehe, des Rätsels Lösung?
Bei immutable Datentypen wird also wirklich eine Kopie erstellt aber ansonsten wird eine Referenz übergeben?
Code: Alles auswählen
class MutableObject(object):
def __init__(self):
self.data = []
def __add__(self, other):
self.data.append(other)
return self
__iadd__ = __add__Code: Alles auswählen
a = MutableObject()
b = a + 5Du solltest dich zuerst Fragen, warum ein Objekt immutable sein kann, beziehungsweise warum das Konzept eines unveränderlichen Objektes relativ sinnvoll ist.Wie schafft man es dann, dass ein selbstdefinierter Datentyp immutable wird?
Ich finds gut. Klar, ist am Anfang vllt etwas verwirrend, aber das wars auch. Es läuft letztendlich nur darauf hinaus, daß das Objekt seine Verhaltensweisen selbst bestimmt und Namen nur eine Art "Zettel" an den Objekten sind, um sie im entsprechenden Namensraum zu halten und anzusprechen. Übergebe ich ein Objekt einem anderen, bestimmt dieses, wie es das erstere aufbewahrt - all das hat nichts mehr mit dem Namensraum, in welchen die Übergabe / Erzeugung stattfand, zutun. Das Verhalten ist so deutlich besser, als alle andere, was ich in anderen Sprache gesehen habe.Und wie bewertet ihr persönlich das ganze Verhalten? Logisch und konsequent und vielleicht auch praktisch, oder fändet ihr es besser, wenn man Referenzen immer explizit angeben müsste, anstatt, dass hier solche Verwirrungen entstehen? So wie das in anderen Sprachen gehandhabt wird, so weit ich da informiert bin.
Ja ich hab mich etwas geschickt ausgedrückt, aber du hast natürlich recht damitBlackJack hat geschrieben:@Nocta: Nicht die Zuweisung kopiert ein "immutable"s Object, sondern eventuell eine Operation, die man darauf aufruft. Auf der Ebene der Zuweisung passiert immer das Gleiche, egal was für ein Objekt da zugewiesen wird.
Naja, in der Physik stellt man sich auch vereinfacht anhand von Modellen Dinge vor, die gar nicht so sindKlar kannst Du Dir vorstellen, dass immutable Objekte kopiert werden. Aber *warum*? Damit hast Du in Gedanken eine Unterscheidung, die keine Auswirkungen hat.
Aber vielleicht hast du auch recht und mein "Modell" vereinfacht das ganze nicht, sondern verkompliziert es.
Okay, wenn man das so sieht, ist es wirklich sinnfrei, noch gemischte Objekte zu unterscheiden. Ich wollte nur noch mal sichergehen, ob ich das ganze richtig verstanden habe.Gemischte Objekte gibt es IMHO nicht.
Weil in der Pyhsik die Modelle wesentlich komplizierter sind. Das Objektmodell in Python ist eigentlich recht simpel, man könnte direkt sagen primitiv. Ab dem Zeitpunkt ab dem man es verstanden aht, dass es eigentlich keine Unterscheidung zwischen Immutablen Objekten und mutablen Objekten gibt wird es direkt schon langweiligNocta hat geschrieben:Naja, in der Physik stellt man sich auch vereinfacht anhand von Modellen Dinge vor, die gar nicht so sind
IMHO kommt es eher darauf an was man mit dem Objekt macht: wenn es immutable ist kann man es verändern ansonsten erstellt man ein *neues* Objekt, das bestimmte Daten aus dem alten Objekt übernimmt.Nocta hat geschrieben:Datentypen sind also nicht zwingend in allen Eigenschaften immutable oder mutable, sondern es kommt darauf an, wie die jeweilige Operation definiert ist.
Wenn ein Datentyp hinsichtlich einer noch so kleinen kleinigkeit Mutabel ist, ist er nicht mehr Immutabel.Nocta hat geschrieben:Datentypen sind also nicht zwingend in allen Eigenschaften immutable oder mutable, sondern es kommt darauf an, wie die jeweilige Operation definiert ist.
Code: Alles auswählen
alice = Human()
bob = Human()
alice.birthday = Date(year=1984, month=5, day=23)
bob.birthday = alice.birthdayCode: Alles auswählen
class Datum(object):
# ...
def add_day(self, days):
self.day += days # jaja, nicht perfektCode: Alles auswählen
alice.birthday.add_days(1)
assert bob.birthday.day == 24Code: Alles auswählen
class Date(object):
# ...
def add_days(self, days):
return Date(year=self.year, month=self.month, day=self.day + days)
alice.birthday = alice.birtday.add_days(1)
assert alice.birthday.day == 24
assert bob.birthday.day == 23