OOP

[Darii]

Der Witz ist, dass bei "special syntax" (und len etc.) die Suche gleich bei der Klasse anfängt und nicht bei der Instanz.

Jein. Tatsachlich hast du Recht, das gilt aber nur für new-Style-Klassen. Naja, „Special cases aren't special enough to break the rules.“ hatten wir ja gerade...

Code: Alles auswählen

>>> list.__len__
<slot wrapper '__len__' of 'list' objects>
>>> len(list)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
TypeError: object of type 'type' has no len()

Was willst du jetzt damit zeigen? Das kann sowieso gar nicht funktionieren, da list.__len__ keine Klassenmethode ist.

[bords0]

Code: Alles auswählen

>>> list.__len__
<slot wrapper '__len__' of 'list' objects>
>>> len(list)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
TypeError: object of type 'type' has no len()

Was willst du jetzt damit zeigen? Das kann sowieso gar nicht funktionieren, da list.__len__ keine Klassenmethode ist.[/quote]

Dass bei len nicht bei der Instanz (hier: list) nach dem Attribut __len__ gesucht wird.

Was Klassenmethoden damit zu tun haben, verstehe ich nicht
len braucht doch keine Klassenmethoden (classmethod)?

[Darii]

Dass bei len nicht bei der Instanz (hier: list) nach dem Attribut __len__ gesucht wird.

Was Klassenmethoden damit zu tun haben, verstehe ich nicht
len braucht doch keine Klassenmethoden (classmethod)?

Ganz einfach, da __len__ keine Klassenmethode ist, könne list.__len__() gar nicht funktionieren, wenn dort danach gesucht würde. Ich hab mir halt die Fehlermeldung nicht durchgelesen.

[DasIch]

Der Witz ist, dass bei "special syntax" (und len etc.) die Suche gleich bei der Klasse anfängt und nicht bei der Instanz. Die Attribute selbst kann man ganz normal nachschlagen.

Irgendwo muss man Kompromisse eingehen damit die Ausführungsgeschwindigkeit nicht völlig in den Keller geht.

[Darii]

Der Dict-Lookup mehr oder weniger bringt einen bei Python jetzt auch nicht um. Sowas zu optimieren ist dann Aufgabe der VM und nicht der Sprache. Aber so ist das einfach nur inkonsistent.

[sma]

Der Dict-Lookup mehr oder weniger bringt einen bei Python jetzt auch nicht um. ;)

Doch, genau dies ist der Grund, warum Python vergleichsweise ineffizient ist und die UnloadenSwallow-Leute so Probleme haben, das System fix zu kriegen.

Sowas zu optimieren ist dann Aufgabe der VM und nicht der Sprache. Aber so ist das einfach nur inkonsistent.

Eine VM kann da wenig machen. Bereits jetzt hat AFAIK CPython eine vtable pro Klasse, wo die ganzen Spezialmethoden, die ja überall aufgerufen werden müssen, eingetragen sind, damit man einen k*O(1) Zugriff mit minimalem k hat. Diese pro Exemplar einer Klasse mitzuschleppen klingt nicht nach einer guten Idee. Daher finde ich die Entscheidung, dass man Spezialmethoden nicht in einzelnen Exemplaren überschreiben kann, verständlich.

Stefan

[Darii]

Der Dict-Lookup mehr oder weniger bringt einen bei Python jetzt auch nicht um.

Doch, genau dies ist der Grund, warum Python vergleichsweise ineffizient ist und die UnloadenSwallow-Leute so Probleme haben, das System fix zu kriegen.

Aber Python ist ja nicht deswegen ineffizient, weil die fünf Spezialmethoden einen zusätzlichen dict-Lookup benötigen, sondern weil das überall der Fall ist.

Sowas zu optimieren ist dann Aufgabe der VM und nicht der Sprache. Aber so ist das einfach nur inkonsistent.

Eine VM kann da wenig machen. Bereits jetzt hat AFAIK CPython eine vtable pro Klasse, wo die ganzen Spezialmethoden, die ja überall aufgerufen werden müssen, eingetragen sind, damit man einen k*O(1) Zugriff mit minimalem k hat. Diese pro Exemplar einer Klasse mitzuschleppen klingt nicht nach einer guten Idee.

Muss man ja auch nicht, so lange das Exemplar sie nicht enthält.

[BlackJack]

@Darii: Ich denke mal die "fünf" Spezielmethoden werden einfach *deutlich* öfter aufgerufen als Andere. Insofern macht das schon Sinn, deren Aufruf zu beschleunigen.