Code: Alles auswählen
class mK(type):
def foo(self,*verwirf): return "gebunden"
#
class K(object):
__metaclass__ = mK
def foo(self): return "ungebunden"
#
oK = K()Code: Alles auswählen
print K.foo(oK) #???
Nein, das ist nicht der Fall - es wird nur in K gesucht. Und wenn du gleich "oK.foo()" aufrufst wird sogar zuerst in "oK" gesucht, falls das nicht mit "__slots__" abgestellt wurde.Goswin hat geschrieben:Bei einem gebundenen Aufruf "K.foo(oK)", wird foo in der Metaklasse_mK gesucht und oK nicht weiter ueberprueft.
Ach, du hast ja so was von recht! *ironisch_grins*Trundle hat geschrieben:Mein Tipp wäre es ja, Metaklassen nicht zu verwenden, wenn man sich das Verhalten nicht erklären kann.
In meinem obigen Beitrag befindet sich 100% des Codes, den ich benutzt habe.Trundle hat geschrieben:der genaue Code, wie du was getestet hast, wäre auch nicht ganz verkehrt, denn aus der Beschreibung werde ich nicht so wirklich schlau..
Das kommt mir auch so vor. Aber mir fällt *ganz_ehrlich* nicht ein, wie ich mich besser erklären kann.Trundle hat geschrieben: ...es sei denn, ich habe dich völlig falsch verstanden.
Ich erwarte vom Forum NICHT, dass es mir meine Probleme löst, sondern mein Metaproblem. Meine Probleme sollten ja MEINE Arbeit sein; mein Metaproblem ist, Python zu lernen ) Soweit ich Python bisher verstanden habe, ist der Ausdruck "K.foo(oK)" mehrdeutig, und in einer Programmiersprache sind Ausdrücke in der Regel eindeutig definiert oder fehlerbehaftet. Ich versuche ganz einfach herauszufinden, wie der Ausdruck "K.foo(oK)" im obigen Kontext von Python ausgelegt wird. Anders gesagt, aufgrund von welchen Überlegungen kann ich voraussagen, dass das obige Programm "ungebunden" und nicht etwa "gebunden" ausgibt?Darii hat geschrieben:Ehrlich gesage verstehe ich genau wie b.esser-wisser nicht, was dein Problem ist. Es wird beide Male in K gesucht.
Wie kommst du darauf?Goswin hat geschrieben:Soweit ich Python bisher verstanden habe, ist der Ausdruck "K.foo(oK)" mehrdeutig,
Deine Bezeichungen "gebunden" bzw. "ungebunden" sind hier sehr ungünstig gewählt, weil Python die englischen Worte dafür ein bisschen anders verwendet (s. Paste).Goswin hat geschrieben:Ich versuche ganz einfach herauszufinden, wie der Ausdruck "K.foo(oK)" im obigen Kontext von Python ausgelegt wird.Anders gesagt, aufgrund von welchen Überlegungen kann ich voraussagen, dass das obige Programm "ungebunden" und nicht etwa "gebunden" ausgibt?
"[...]wenn du dich fragst, ob du [Metaklassen] brauchst, brauchst du sie nicht"Tim Peters hat geschrieben: "Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don't."
—Tim Peters
Der Ausdruck ist insofern mehrdeutig, als das Python dynamisch typisiert ist und es von den Konkreten Typen von K und oK abhängt was passiert. Er ist insofern eindeutig als das festgelegt ist wie dieser Ausdruck behandelt wird, was genau dabei passiert hatte sma hier mal sehr schon dargelegt)Goswin hat geschrieben:Soweit ich Python bisher verstanden habe, ist der Ausdruck "K.foo(oK)" mehrdeutig, und in einer Programmiersprache sind Ausdrücke in der Regel eindeutig definiert oder fehlerbehaftet.
Er ist in dem Fall identisch zu oK.foo()Ich versuche ganz einfach herauszufinden, wie der Ausdruck "K.foo(oK)" im obigen Kontext von Python ausgelegt wird.
Warum kommst du überhaupt auf die Idee, dass da überhaupt "gebunden" ausgegeben werden sollte.Anders gesagt, aufgrund von welchen Überlegungen kann ich voraussagen, dass das obige Programm "ungebunden" und nicht etwa "gebunden" ausgibt?
Code: Alles auswählen
class mK(type):
def foo(self,*verwirf): return "gebunden"
#
class K(object):
__metaclass__ = mK
#
oK = K()
print K.foo(oK) # gebunden
print oK.foo() # AttributeErrorhttp://docs.python.org/reference/datamodel.html#invoking-descriptors hat geschrieben:The default behavior for attribute access is to get, set, or delete the attribute from an object’s dictionary. For instance, a.x has a lookup chain starting with a.__dict__['x'], then type(a).__dict__['x'], and continuing through the base classes of type(a) excluding metaclasses.
Code: Alles auswählen
class mK(type):
def foo(self,*verwirf): return "gebunden"
class K(object):
__metaclass__ = mK
print K.foo() # gebunden
print mK.foo(K) # gebundenCode: Alles auswählen
def foo1(instance, greeting):
return greeting
def foo2(instance, num):
return ' '.join(instance.piep() for i in range(num))
def foo3(instance, num, greet):
return ' '.join(instance.foo1(greet) for i in range(num))
class mK(type):
def __init__(self, *args):
self.foo1 = foo1
self.foo2 = foo2
self.foo3 = foo3
class K(object):
__metaclass__ = mK
def piep(self):
return 'Piep'
instance = K()
print instance.foo1('hello') # hello
print instance.foo2(3) # Piep Piep Piep
print instance.foo3(3, 'hello') # hello hello helloEinfache Beispiele zur Veranschaulichung von OOP-Konzepten sind meistens fragwürdig. Python bietet viel Spielraum hinsichtlich der Umsetzung, zwischen einfachen Funktiondefinitionen bis hin zu Metaklassen führen viele Wege nach Rom. (Man könnte ja auch komplett auf das class-Konstrukt verzichten und alles in einer cleveren Schachtelung von Funktionen und Modulen vornehmen usw.)Das ist aber einfach nur eine Attributzuweisung, das kann man wenn man will auch in der __init__ der Klasse machen. Oder auch einfach so (wobei das je nachdem wann es geschieht Monkey Patching ist, siehe Forensuche)
Die type-Initialisierung ist hier irrelevant, da die Klassensignatur nicht geändert wird sondern nur die Instanzen um Methoden erweitert werden.Außerdem rufst du in deiner Metaklasse nicht die __init__ von type auf.
Natürlich wird die Klasse geändert, dazu ist die __init__-Methode der Metaklassen da. Eine Instanz von K wird erst mit der __call__-Methode der Metaklasse erzeugt und ist daher noch gar nicht bekannt. Und um dies nicht zu verwechseln schreibt man innerhalb der Metaklassen nicht "self" sonder "cls".jerch hat geschrieben:Die type-Initialisierung ist hier irrelevant, da die Klassensignatur nicht geändert wird sondern nur die Instanzen um Methoden erweitert werden.
Du überschreibst doch den Initialisator von type. Da type eine recht komplexe Klasse ist, gehe ich davon aus, das __init__ einige Dinge tun wird. Zumindest hab ich in der Doku noch keine genaue Beschreibung von type gefunden, aber man kann es annehmen, eben wegen der Komplexität. Insofern sollte man immer __init__ einer Superklasse aufrufen, wenn man nicht genau weiß, was man tut. Oder weißt du *genau*, das type.__init__ nichts macht? Wenn ja, dann kann man es weglassen, ich schätze die Möglichkeit als sehr gering ein.Die type-Initialisierung ist hier irrelevant, da die Klassensignatur nicht geändert wird sondern nur die Instanzen um Methoden erweitert werden.
Code: Alles auswählen
class mK(type):
print "Erzeuge MetaKlasse mK"
def __new__(cls, *args):
print "mK: __new__", type(cls)
return type.__new__(cls, *args)
def __init__(cls, *args):
print "mK: __init__", type(cls)
super(mK, cls).__init__(*args)
def __call__(cls, *args):
print "mK: __call__", type(cls)
return super(mK, cls).__call__(*args)
print mK
class K(object):
print "Erzeuge Klasse K, instantiiert von mK"
__metaclass__ = mK
def __new__(cls, *args):
print "K: __new__", type(cls)
return object.__new__(cls, *args)
def __init__(self):
print "K: __init__", type(self)
print K
print 'Erzeuge Instanz, ruft __call__ von mK auf'
instance = K()
print instanceCode: Alles auswählen
Erzeuge MetaKlasse mK
<class '__main__.mK'>
Erzeuge Klasse K, instantiiert von mK
mK: __new__ <type 'type'>
mK: __init__ <class '__main__.mK'>
<class '__main__.K'>
Erzeuge Instanz, ruft __call__ von mK auf
mK: __call__ <class '__main__.mK'>
K: __new__ <class '__main__.mK'>
K: __init__ <class '__main__.K'>
<__main__.K object at 0x80a494c>Code: Alles auswählen
class Husten(object):
def __new__(cls, *args):
print "Husten: __new__", type(cls)
return object.__new__(cls, *args)
def __init__(self):
print "Husten: __init__", type(self)
Husten()
#--->
# Husten: __new__ <type 'type'>
# Husten: __init__ <class '__main__.Husten'>... schnipp ...Darii hat geschrieben:Ich glaube worauf du hinauswillst ist folgender Fall, oder?
In der Tat scheint das die Situation zu beschreiben und löst die Mehrdeutigkeit auf, indem es den Metaklassen eine niedrigere Priorität als den Klassen einräumt. Der Themenstrang müsste vielleicht heißen "Attributsuche kommt vor Klassensuche wenn beides möglich ist" oder "Objektbindung kommt vor Klassenbindung wenn beides möglich ist".http://docs.python.org/reference/datamodel.html#invoking-descriptors hat geschrieben:The default behavior for attribute access is to get, set, or delete the attribute from an object’s dictionary. For instance, a.x has a lookup chain starting with a.__dict__['x'], then type(a).__dict__['x'], and continuing through the base classes of type(a) excluding metaclasses.