Merkwürdiges Struct-ähnliches Element

[darktrym]

Verzeihung, mir ist einfach kein besserer Titel dazu eingefallen.
Heute bin ich etwas merkwürdigen begegnet und kann nicht erklären wieso das erlaubt ist, funktioniert und ob es irgendwie sinnvoll ist.
Aktiv in Verwendung hab ich das gesehen, fand es da aber wenig sinnvoll.

Code: Alles auswählen

def a(): pass
a.p = True

p taucht dann im Namensraum von a auf(dir(a)).

[EyDu]

Funktionen sind nicht anderes als Objekte, daher kannst du mit ihnen alles machen, was du mit anderen Objekten auch machst. "p" befindet sich auch nicht im Namensraum von "a", das ist etwas anderes, sondern ist ein ganz normales Attribut.

[darktrym]

Irgendwie verhälts sich wie ein Funktionszeiger oder warum gibt er eine Adresse da zurück?

Code: Alles auswählen

def n():
    print(n.d)

n.d = 1

[Sirius3]

@darktrym: ich verstehe nicht, was Du mit „Funktionszeiger“ meinst. »n« ist innerhalb von »n ein ganz normales globales Objekt.

[darktrym]

Was heißt denn hier normal?
Außerhalb ist es eine "normale" Variable innerhalb ein "normaler" Verweis.
Gibts ein Begriff/Referenz wo man sich drüber informieren kann wieso das so ist?

[BlackJack]

@darktrym: `n` ist sowohl ausserhalb als auch innerhalb der Funktion ein Name der auf Modulebene definiert ist.

Was Du da gerade mit Funktionszeiger, Verweis, und Adresse sagen willst verstehe ich nicht. Das gibt es in Python nicht. In Python gibt es Namen und Werte, und *alles* was man an einen Namen binden kann, also *jeder* Wert, *ausnahmslos*, ist ein Objekt. Und bei den meisten Objekten kann man zur Laufzeit neue Attribute hinzufügen.

Edit: Und das heisst in diesem Zusammenhang „normal”, denn das sollte man von Objekten in Python eigentlich erwarten und nicht überrascht sein.

[darktrym]

Habs jetzt gefunden, das da nennt sich Funktionsattribute beschrieben in PEP232.

[BlackJack]

@darktrym: Ich denke Du siehst das immer noch als etwas zu spezielles an statt einfach als ganz normale Attribute auf einem Objekt. Das PEP war nur nötig weil Funktionsobjekte vorher kein `__dict__`-Attribut hatten.

[darktrym]

Funktioniert das auch mit was anderem außer Funktionen und Klassen/Instanzen?
Für mich ist das nicht schlüssig warum eine Funktion ein Objekt sein muss wenn alles andere das nicht ist.
Bei Klassen/Instanzen kann ich der Idee was abgewinnen aber Funktionen?

Wenn ADT wie Listen und Wörterbücher Attribute und Methoden besitzen und somit zu Objekten macht, wieso funktioniert das nicht bei denen?

[BlackJack]

@darktrym: Was meinst Du mit alles andere wäre kein Objekt? Nochmal: *Alles* was man an einen Namen binden kann ist ein Objekt in Python.

Die Typen die Du aufgezählt hast sind alle in C programmiert und wenn man einen Typ in C programmiert, muss man explizit dafür sorgen dass Exemplare davon ein `__dict__` haben und damit beliebige Attribute zur Laufzeit gesetzt werden können. Umgekehrt geht es auch: man kann bei in Python implementierten Typen verhindern das Exemplare ein `__dict__` haben, in dem man die Attribute mit `__slots__` festlegt.

[Leonidas]

Funktioniert das auch mit was anderem außer Funktionen und Klassen/Instanzen?
Für mich ist das nicht schlüssig warum eine Funktion ein Objekt sein muss wenn alles andere das nicht ist.
Bei Klassen/Instanzen kann ich der Idee was abgewinnen aber Funktionen?

Dann ist da doch kein Problem, weil Funktionen sind Instanzen der Klasse ``function``. Und dass sie Objekte sind, ist nützlich, damit kannst du mit Funktionen tolle Sachen machen. Sie zum Beispiel als Parameter an andere Funktionen übergeben. Oder sie an Namen binden.

Wenn ADT wie Listen und Wörterbücher Attribute und Methoden besitzen und somit zu Objekten macht, wieso funktioniert das nicht bei denen?

Weil es dort speziell verboten wurde, an diese Attribute hinzuzufügen. Die Idee dahinter war zu verbieten dass irgendwelche Libraries die "Basissprache" soweit verändern, dass ggf andere Libraries dann nicht mehr funktionieren weil etwa jemand bei Listen die ``append``-Methode durch irgendwas anderes ersetzt hat.