Naja, weil da einige dagegen waren die printf-Syntax rauszunehmen (das war ursprünglich geplant). Generell ist aber das neue Format idR. zu bevorzugen. Ist ja auch klarer.hendrikS hat geschrieben:Wozu dann eigentlich das format attribute.
String verarbeiten, erster und letzter Buchstabe
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das ist doch kein Mißbrauch. % ist halt in Zusammenhang mit verschiedenen Typen auch verschieden anzuwenden.DasIch hat geschrieben: Du findest es also elegant den Modulo Operator zu missbrauchen?
Genauso bei +. Summe oder Konkatinieren. Zwei paar Schuhe. Oder willst Du Strings/Listen zukünftig nicht mehr mit + verbinden können dürfen.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Doch ist es. Unter einer Listenaddition würde man das Verbinden von Listen verstehen (oder eventuell eine komponentenweise Addition), aber was wäre semantisch der Rest der Division von einem String durch einen String oder ein Tupel?hendrikS hat geschrieben:Das ist doch kein Mißbrauch. % ist halt in Zusammenhang mit verschiedenen Typen auch verschieden anzuwenden.
Genauso bei +. Summe oder Konkatinieren. Zwei paar Schuhe. Oder willst Du Strings/Listen zukünftig nicht mehr mit + verbinden können dürfen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Exakt dass ist es. Wenn ich Sequenzen mit + verbinden kann ist dass durchaus noch logisch und nachvollziehbar aber was bitteschön ergibt Modulo für Strings und wenn Modulo geht was bewirkt dann erst eine Division?hendrikS hat geschrieben:Zwei paar Schuhe.
Hier wurde einfach der nächst beste Operator genommen und missbraucht.
Ein Glück dass das demnächst deprecated wird.
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.
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.
nein. % bietet sich an, da er der C format-operator ist.Hier wurde einfach der nächst beste Operator genommen und missbraucht.
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...
jetzt doch, wo steht das?Ein Glück dass das demnächst deprecated wird.
bitte nicht...
http://www.kinderpornos.info
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Nicht jeder Python-Programmierer kommt von C. Also doch, einige.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...
wenn schon dann sollen sie den modulo-op in "mod" umbenennen...
Nicht "jetzt doch", wir haben vorher gesagt dass es nicht entfernt wird. Zwischen deprecaten und entfernen gibt es ja durchaus einen Unterschied.Dill hat geschrieben:jetzt doch, wo steht das?Ein Glück dass das demnächst deprecated wird.
bitte nicht...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.
@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.
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.
Wenn du ein dict verwendest, geht das. Bei einem tuple aber nicht.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?
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
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.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.
Und das ist nicht zu unterschätzen. Nicht umsonst hat z.B. Qt seine eigene Syntax erfunden ("%1 %2").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.