Seite 2 von 2
Verfasst: Sonntag 3. Mai 2009, 11:48
von hendrikS
Na, wie dem auch sei. Ich finds nicht schlimm % zur Formatierung einzusetzen. Kann bis jetzt sehr gut damit leben.
So lange ich mir über die Semantik der Operatoren im Klaren bin.
Ich meine, es gibt andere Baustellen, wie z.Bsp. Performance oder die Abgrenzung von Listen und Tuples (hatte ich glaube ich neulich schon mal kurz erwähnt), wo man hätte mal was machen können. Aber das war ja nicht das Thema des OP.
Verfasst: Sonntag 3. Mai 2009, 11:55
von Dill
Hier wurde einfach der nächst beste Operator genommen und missbraucht.
nein. % bietet sich an, da er der C format-operator ist.
der war schon format - op, da bist du noch der blaßmusik hinterhergelaufen =) (!!)
wen verwirrt das denn bitte ernsthaft? niemanden...
wenn schon dann sollen sie den modulo-op in "mod" umbenennen...
Ein Glück dass das demnächst deprecated wird.
jetzt doch, wo steht das?
bitte nicht...
Verfasst: Sonntag 3. Mai 2009, 12:21
von Leonidas
Dill hat geschrieben:nein. % bietet sich an, da er der C format-operator ist.
der war schon format - op, da bist du noch der blaßmusik hinterhergelaufen =) (!!)
wen verwirrt das denn bitte ernsthaft? niemanden...
Nicht jeder Python-Programmierer kommt von C. Also doch, einige.
wenn schon dann sollen sie den modulo-op in "mod" umbenennen...
Dill hat geschrieben:
Ein Glück dass das demnächst deprecated wird.
jetzt doch, wo steht das?
bitte nicht...
Nicht "jetzt doch", wir haben vorher gesagt dass es nicht entfernt wird. Zwischen deprecaten und entfernen gibt es ja durchaus einen Unterschied.
Verfasst: Sonntag 3. Mai 2009, 12:21
von DasIch
5.6.2 Old String Formatting Operations hat geschrieben:Note
The formatting operations described here are obsolete and may go away in future versions of Python. Use the new String Formatting in new code.
Verfasst: Sonntag 3. Mai 2009, 12:57
von BlackJack
@hendrikS: Die neue Art zu formatieren hat einige Vorteile gegenüber der alten. Zum Beispiel kann man sich jetzt für eigene Objekte eine `__format__()`-Methode schreiben, die Optionen für die Formatierung kennt. Dass man das im Grunde nur für Zahlen detaillierter machen und sonst für alle anderen Objekte nur die Breite angeben konnte, war eine künstliche Einschränkung.
Und durch die Nummerierung der Platzhalter kann man die Reihenfolge unabhängig von der Reihenfolge der Argumente machen. Darüber freuen sich Übersetzer, weil nicht in allen Fällen eine gute, natürlich klingende Übersetzung gelingt, wenn die Reihenfolge festgelegt ist.
Verfasst: Sonntag 3. Mai 2009, 13:11
von Dill
>Und durch die Nummerierung der Platzhalter kann man die Reihenfolge unabhängig von der Reihenfolge der Argumente machen.
das geht doch auch mit %, oder?
Verfasst: Sonntag 3. Mai 2009, 13:30
von helduel
Dill hat geschrieben:>Und durch die Nummerierung der Platzhalter kann man die Reihenfolge unabhängig von der Reihenfolge der Argumente machen.
das geht doch auch mit %, oder?
Wenn du ein dict verwendest, geht das. Bei einem tuple aber nicht.
Verfasst: Sonntag 3. Mai 2009, 16:52
von birkenfeld
BlackJack hat geschrieben:@hendrikS: Die neue Art zu formatieren hat einige Vorteile gegenüber der alten. Zum Beispiel kann man sich jetzt für eigene Objekte eine `__format__()`-Methode schreiben, die Optionen für die Formatierung kennt. Dass man das im Grunde nur für Zahlen detaillierter machen und sonst für alle anderen Objekte nur die Breite angeben konnte, war eine künstliche Einschränkung.
Was ich daran auch schlüssiger finde, ist die Verwendung mit Dictionaries als RHS; die meisten haben wohl schon mal ein "s" hinter "%(key)" vergessen. Außerdem ist das sehr verwirrende Problem mit ``"%s" % b`` gelöst, wenn "b" auf einmal auch ein Tupel sein kann.
Und durch die Nummerierung der Platzhalter kann man die Reihenfolge unabhängig von der Reihenfolge der Argumente machen. Darüber freuen sich Übersetzer, weil nicht in allen Fällen eine gute, natürlich klingende Übersetzung gelingt, wenn die Reihenfolge festgelegt ist.
Und das ist nicht zu unterschätzen. Nicht umsonst hat z.B. Qt seine eigene Syntax erfunden ("%1 %2").