Re: [Python-de] strings zusammensetzen.

Tobias Herp tobias.herp@gmx.de writes:
Оlе Ѕtrеісhеr schrieb am 25.08.2017 um 10:47:
"Tobias Herp" tobias.herp@gmx.de writes:
a b und c enthalten strings.
d=a+b+c besser als # Variante 1 d="{}{}{}".format(a,b,c) ? # Variante 2
Die zweite Variante ist das übliche Idiom, wenn es um die Kombination von Strings geht.
Wirklich? Himmel hilf!
Das hängt IMO stark vom Use-Case ab. Oft hat man z.B. solche String-Concatenierungen im Zusammenhang mit der Erstellung von Dateinamen. Und da wäre es besser, ein Template zu verwenden -- genau im Sinne von "explizit ist besser als implizit":
Nur dadurch, daß etwas umständlich programmiert ist, wird es noch nicht expliziter. Und umständlich ist es, wenn man zum Hinzufügen einer weiteren Variablen zwei Änderungen vornehmen muß.
Das hängt eben von der Anwendung ab. Wenn die Aufgabe war, "n gleichwertige Strings concatenieren mit dem Spezialfall n=3", hast Du recht.
Wenn die Aufgabe ist "einen String aus semantisch unterschiedlichen Strings nach einer bestimmten Regel erzeugen (und die Regel ist erstmal die einfache Aneinanderfügung)", dann ist format() besser. In diesem Fall ist auch klar, dass eine Erweiterung typischerweise zwei Änderungen erfordert: einmal muss die Regel selbst geändert werden, und dann muss man natürlich die zugehörigen Daten zur Verfügung stellen.
d = "{base}{revision}{suffix}".format(base = a, revision = b, suffix = c)
Wenn's denn unbedingt ein Template sein soll, würde das bei mir meistens wie folgt aussehen:
d = '%(base)s%(revision)s%(suffix)s' % locals()
Warum sollte man die veraltete Form mit "%" verwenden?
(natürlich nennt *niemand* seine Variablen a, b und c, bzw. würde es nach Lektüre dieses Threads niemals zugeben...)
a, b und c habe ich hier als Platzhalter interpretiert, nicht notwendig als Variablen.
Im übrigen kann es natürlich jedem Stück Code in einem größeren Projekt (oder in einer Server-Anwendung) passieren, daß es sehr oft durchlaufen wird. Und spätestens dann spielt die Performanz eine Rolle. Die .format-Methode bezahlt für ihre (ich behaupte: in mindestens 95% der Fälle nicht benötigte) zusätzliche Flexibilität mit sehr viel schlechterer Performanz.
Man sollte nicht zu früh optimieren, und Lesbarkeit geht häufig über Effizienz. In dem von mir gebrachten Beispiel (Generierung eines Dateinamens): Nach der Bildung eines Dateinamens erfolgt fast immer eine I/O-Operation mit dieser Datei, und die ist viel langsamer als jede String-Format-Operation. Und zwar selbst dann, wenn sie "irgendwann" mal in einer Server-Anwendung läuft.
Allgemein würde ich, wenn es sich um Strings handelt, immer genau schauen, ob man nicht eigentlich ein Template füllen möchte, das nur gerade zufällig sehr einfach ausfällt.
Man kann es auch übertreiben mit der vorausschauenden Komplexität. Wie heißt es doch so schön - YAGNI! You ain't gonna need it!
Man sollte sich einfach Gedanken um seinen Code machen, bevor man ihn schreibt. Gerade im Fall der Generierung von Dateinamen habe ich zu Anfang häufig einfach Strings concateniert, und (weils so einfach ist) das auch noch gleich lokal da, wo ichs brauchte. Wenn dann jemand kam und einen zusätzlichen Bindestrich drin haben wollte, habe ich geflucht und alle Stellen, wo ich den Dateinamen zusammengebaut habe, wieder herausgesucht und geändert. Ein (gemeinsames) Template für diese Stellen vermeidet das bei mir in neueren Projekten, selbst wenn das meist erstmal so aussieht wie oben (und damit einfach drei Strings concateniert).
Schöne Grüße
Ole
P.S. Ich brauche keine Mailkopie.
participants (1)
-
ole-usenet-spam@gmx.net