Tobias Herp <tobias.herp(a)gmx.de> writes:
> Оlе Ѕtrеісhеr schrieb am 25.08.2017 um 10:47:
>> "Tobias Herp" <tobias.herp(a)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.