So. Ich versuche mich gerade, in meiner verlängerten Pause in die Methodik hereinzulesen, wie blackbird's Tekisuto funktioniert...
Da dort sehr viel via überladene Operatoren erledigt wird wollte ich mir hier bei einigen Sachen nochmal Klarheit verschaffen.
Fangen wir mal an.
''__new__'' und ''__init__'' hab ich schonmal verstanden.
genauso wie ''__str__''. Das klappt :=)
Jedoch... gibt es dort z.B.
''__repr__''. hier verstehe ich nur Bahnhof. Selbst die Dokumentation hilft mir nicht weiter... Was genau macht __repr__() ?
''__lt__( self, other) ''
''__le__( self, other) ''
''__eq__( self, other) ''
''__ne__( self, other) ''
''__gt__( self, other) ''
sagen mir genauso wenig. Mein Buch sowie die Dokumentation geben mir hier auch keine Auskunft.
Ich kann nur raten, das sie indirekt etwas mit ''__cmp__'' zu tun hat.
Habt ihr dort genauere Informationen - Dokumentationen - Artikel?
Würde mich freuen
MfG EnTeQuAk
Ein paar Fragen über das überladen von operatoren...
- sunmountain
- User
- Beiträge: 89
- Registriert: Montag 13. März 2006, 17:18
Naja, das zeigt dir genau an was in der Klasse/Instanz ist wenn du ``repr(foo)`` aufrufst.EnTeQuAk hat geschrieben: ''__repr__''. hier verstehe ich nur Bahnhof. Selbst die Dokumentation hilft mir nicht weiter... Was genau macht __repr__() ?
Code: Alles auswählen
str_ = u"fööbär"
print repr(str_) # u'f\xf6\xf6b\xe4r'
Dann hast du die falsche. http://docs.python.org/ref/customization.htmlEnTeQuAk hat geschrieben: ''__lt__( self, other) ''
''__le__( self, other) ''
''__eq__( self, other) ''
''__ne__( self, other) ''
''__gt__( self, other) ''
sagen mir genauso wenig. Mein Buch sowie die Dokumentation geben mir hier auch keine Auskunft.
x<y = calls x.__lt__(y), x<=y calls x.__le__(y), etc
BTW: __new__ habe ich nicht verstanden. Wie geht das genau?
lg
ACH DAAA
Die Seite hab ich mir schon angeschaut gehabt... nur habe ich den Absatz, unter den Sachen, da nur für das ''__ge__'' gesehen
Sorry. Ich dachte, die hätten nicht alle ganz so viel miteinander zu tun.
Hmmm... ''__repr__'' schaut doch schon schick aus. so langsam komme ich hinter die Arbeitsweise einiger Lexer
MfG EnTeQuAk
Die Seite hab ich mir schon angeschaut gehabt... nur habe ich den Absatz, unter den Sachen, da nur für das ''__ge__'' gesehen
Sorry. Ich dachte, die hätten nicht alle ganz so viel miteinander zu tun.
Hmmm... ''__repr__'' schaut doch schon schick aus. so langsam komme ich hinter die Arbeitsweise einiger Lexer
MfG EnTeQuAk
Btw:
ich hab grad lokal hier Python zum laufen bekommen und '__repr__' ausprobieren können.
folgendes ist herausgekommen:
So... verwirrt vllt
Aber wenn man
dann kommt alles heraus, wofür __repr__ da ist
So... die anderen schau ich mir dann aúch gleich mal an.
MfG EnTeQuAk
ich hab grad lokal hier Python zum laufen bekommen und '__repr__' ausprobieren können.
folgendes ist herausgekommen:
Code: Alles auswählen
class Test(object):
def __init__(self):
self.da = 'da'
def __repr__(self):
return ''.join(self.__class__.__name__)
# und testen
da = Test()
repr(da)
print da
Aber wenn man
Code: Alles auswählen
class Test2(object):
def __init__(self):
self.da = 'da'
def __str__(self):
return self.da
def __repr__(self):
return ''.join(self.__class__.__name__)
# und testen
da = Test()
repr(da)
print da
So... die anderen schau ich mir dann aúch gleich mal an.
MfG EnTeQuAk
Darf man fragen, was der Gedanke hinter ist, insbesondere hinter dem join(...)?
self.__class__.__name__ wird dir afaik immer einen string wiedergeben (den Namen der Klasse, die dir __class__ zurückgibt).
Natürlich kann man den joinen, weil er als String iterabel ist, aber imho sollte für alle Strings gelten
Zu __repr__ möchte ich anmerken, dass es meines Wissens "deprecated" ist.
Code: Alles auswählen
def __repr__(self):
return ''.join(self.__class__.__name__)
self.__class__.__name__ wird dir afaik immer einen string wiedergeben (den Namen der Klasse, die dir __class__ zurückgibt).
Natürlich kann man den joinen, weil er als String iterabel ist, aber imho sollte für alle Strings gelten
Code: Alles auswählen
s == ''.join(s)
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das macht null SinnEnTeQuAk hat geschrieben:Code: Alles auswählen
# und testen da = Test() repr(da) print da
So geht's ehr:
Code: Alles auswählen
# und testen
da = Test()
print repr(da)
EDIT:
das mit dem testen da oben war in einer Python-Shell-Sitzung. daher machte das schon ein klein wenig sinn, da mir das dort ausgegeben wurde -- sorry hab ich vergessen zu erwähnen
Wie an den Klassennamen zu merken es war nur ein Test. Daher habe ich mir über Sinn und Unsinn mal keine Gedanken gemacht.
Oder was war bei dir der Hintergedanke?
MfG EnTeQuAk
das mit dem testen da oben war in einer Python-Shell-Sitzung. daher machte das schon ein klein wenig sinn, da mir das dort ausgegeben wurde -- sorry hab ich vergessen zu erwähnen
Wie an den Klassennamen zu merken es war nur ein Test. Daher habe ich mir über Sinn und Unsinn mal keine Gedanken gemacht.
hmm... warum?Zu __repr__ möchte ich anmerken, dass es meines Wissens "deprecated" ist.
bin ich auf dem falschen Dampfer oder macht das nur für mich keinen Sinn, da da so oder so 'True' rauskommt?Natürlich kann man den joinen, weil er als String iterabel ist, aber imho sollte für alle Strings geltenCode: Alles auswählen
s == ''.join(s)
Oder was war bei dir der Hintergedanke?
MfG EnTeQuAk
[warum ist repr deprecated]
Nagele mich nicht drauf fest, ich erinnere mich, da was gelesen zu haben, was darauf rauslief, dass es kaum einer richtig benutzt (soll heissen: repr gibt etwas aus, was nicht nur hübsch aussieht, sondern auch ein legales python-statement ist), und man es deshalb eigentlich eh nicht benutzen kann. Kann ich eigentlich ganz gut nachvollziehen, und es hindert ja niemanden daran, für sich ein "representable"-Protokoll zu erfinden.
Nagele mich nicht drauf fest, ich erinnere mich, da was gelesen zu haben, was darauf rauslief, dass es kaum einer richtig benutzt (soll heissen: repr gibt etwas aus, was nicht nur hübsch aussieht, sondern auch ein legales python-statement ist), und man es deshalb eigentlich eh nicht benutzen kann. Kann ich eigentlich ganz gut nachvollziehen, und es hindert ja niemanden daran, für sich ein "representable"-Protokoll zu erfinden.
Doch, doch, du hast recht, es kommt immer True raus: das ganze ist eine Tautologie, deshalb sagte ich ja "es gilt für alle strings". Eigentlich wollte ich damit zeigen, dass dein Statement nicht falsch (im Sinne der Funktionalität), sondern nur unnötig kompliziert ist, weil ich annahm, dass sei Absicht.bin ich auf dem falschen Dampfer oder macht das nur für mich keinen Sinn, da da so oder so 'True' rauskommt?
ACHSOOOOO
Dann haben wir uns ja im Enddefekt verstanden
Und ich bin wieder einen Schritt weiter in Python gekommen... Ich mag es
MfG EnTeQuAk
Dann haben wir uns ja im Enddefekt verstanden
Und ich bin wieder einen Schritt weiter in Python gekommen... Ich mag es
MfG EnTeQuAk
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Ist es nicht.keppla hat geschrieben: Zu __repr__ möchte ich anmerken, dass es meines Wissens "deprecated" ist.
`repr` muss nicht "legales Python" zurückgeben. Wenn das einfach möglich ist, wäre es schön, aber es muss nicht. Falls es nicht möglich ist, wird empfohlen etwas aussagekräftiges zurückzugeben, das in '<…>' eingeschlossen ist. Und das habe ich bisher auch so ziemlich überall so implementiert gesehen.keppla hat geschrieben:[warum ist repr deprecated]
Nagele mich nicht drauf fest, ich erinnere mich, da was gelesen zu haben, was darauf rauslief, dass es kaum einer richtig benutzt (soll heissen: repr gibt etwas aus, was nicht nur hübsch aussieht, sondern auch ein legales python-statement ist), und man es deshalb eigentlich eh nicht benutzen kann. Kann ich eigentlich ganz gut nachvollziehen, und es hindert ja niemanden daran, für sich ein "representable"-Protokoll zu erfinden.
Ich wüsste auch nicht wie man ein Python-Programm debuggen sollte, ohne mit `repr()` nachschauen zu können, an was bestimmte Namen wirklich gebunden sind.
ok, ich sollte mich etwas näher an das RFC, was "muss", "soll", "kann" definiert halten.`repr` muss nicht "legales Python" zurückgeben
Ich hab nochmal etwas gesucht, und da, wo ich dachte, ich hätte es gelesen, nichts solches gefunden, und muss mich dementsprechend für das verbreiten von falschinformationen entschuldigen: ich hatte da was falsch in Erinnerung, birkenfeld hat recht.
Code: Alles auswählen
Ich wüsste auch nicht wie man ein Python-Programm debuggen sollte, ohne mit `repr()` nachschauen zu können, an was bestimmte Namen wirklich gebunden sind.
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Dann unterscheide doch mal anhand von str() "1" und 1.keppla hat geschrieben: dazu braucht man nicht unbedingt die Unterscheidung str und repr, z.B. Java kommt auch mit nur .toString aus.
Oder "1.0" und 1.0. Oder...
Um da den Durchblick zu behalten, musst du zumindest den Typ noch mit dazu ausgeben. Genau das macht aber repr().
id() bringt dir garnix.id() ist ausserdem eindeutiger
In wiefern eindeutiger? Mit einer Zahl kann ich persönlich ohne andere Informationen wenig anfangen. Und das was repr ausgibt oder ausgeben sollte ist ja ein wenig mehr als nur eine Zahl (Oder "Adresse" im Default mode).keppla hat geschrieben: dazu braucht man nicht unbedingt die Unterscheidung str und repr, z.B. Java kommt auch mit nur .toString aus. id() ist ausserdem eindeutiger
Ich finde es z.B. nicht schlecht das ich mit __str__ mir nur das anzeigen lassen kann was wichtig ist nach ausenhin, aber mit __repr__ (zusätzlich) ein wenig mehr Daten über Interna Das hilf schon beim Debuggen, wenn man weiß womit man es zu tun hat. Ich überlade __repr__ auch so ähnlich wie im Tekisuto-Code von BlackBird.
Also kurz: Für mich gehört es einfach dazu, dass wenn ich repr(foo) nutze, mir der Name der Klasse zurückgegeben wird, damit ich weiß an was der Name `foo` gebunden ist (Ist im Default ja schon so + "Addresse", etc).
Oft genügen mir diese Information nicht und will ein par Infos (Ohne nötigen Schreibkram) über das interne mehr haben und überlade __repr__ da entsprechend. Wichtig ist aber, dass in der Überladung IMHO immer zusätlich sowas ``self.__class__.__name__`` zurückgegeben werden muss, damit man auch sieht an was ``foo`` gebunden ist.
BTW: Daher finde ich id() auch unpassend, da ich mit einer ID immer eine eindeutige (Kollisionsfreie) Zahl, assoziiere.
lg
EDIT:
BTW: Außerdem ist id() schon von Python als Keyword belegt Es sein den du meintest das du die Benutzung von id() eindeutiger findest
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Klar meint er das. Aber id() ist kein Keyword, sondern eine Funktion in den Builtins.sape hat geschrieben: BTW: Außerdem ist id() schon von Python als Keyword belegt Es sein den du meintest das du die Benutzung von id() eindeutiger findest
Wenn ich wissen will, an _welches_ Objekt ein name gebunden ist, bringt mir das mehr als eine (möglicherweise gleich aussehende) Ausgabe eines __repr__. Das meinte ich auch mit eindeutiger:id() bringt dir garnix
Code: Alles auswählen
d1 = datetime(2007,1,31)
d2 = datetime(2007,1,31)
assert repr(d1) == repr(d2)
assert d1 is not d2
Da gucke ich lieber debugger nach, da habe ich dann auch einen ganzen Haufen andere infos. Ich bin kein so großer Freund von Printlining.Dann unterscheide doch mal anhand von str() "1" und 1.
Oder "1.0" und 1.0. Oder...
Um da den Durchblick zu behalten, musst du zumindest den Typ noch mit dazu ausgeben. Genau das macht aber repr().
Tests auf Objektidentität ist nur in wenigen Fällen wirklich sinnvoll/interessant. Bei `datetime` fällt mir da überhaupt kein Grund ein. Werte und Typen sind eher interessant. Wobei ein nicht unbeträchtlicher Teil von Klassen `__repr()__` gar nicht überschreibt, man also Typ und Identität auf einmal bekommt.keppla hat geschrieben:Wenn ich wissen will, an _welches_ Objekt ein name gebunden ist, bringt mir das mehr als eine (möglicherweise gleich aussehende) Ausgabe eines __repr__. Das meinte ich auch mit eindeutiger:id() bringt dir garnix
Code: Alles auswählen
d1 = datetime(2007,1,31) d2 = datetime(2007,1,31) assert repr(d1) == repr(d2) assert d1 is not d2
Tests auf Objektidentität ist nur in wenigen Fällen wirklich sinnvoll/interessant.
Ich hatte das so aus der Beschreibung rausgelesen (welches objekt an einen namen gebunden ist).
Das war auch eher des Beispiels wegen, ich hab halt ne vorhandene Klasse gewählt.Bei `datetime` fällt mir da überhaupt kein Grund ein.