[Python-de] strings zusammensetzen.

[Stefan Schwarzer]

On 2017-08-25 10:28, Tobias Herp wrote:
>>> 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!

Erst mal vorweg. Ich denke, dass es für dieses Problem (Strings
zusammenfassen) nicht so kritisch ist, welche der drei Varianten
(`format`, `+` oder `join`) man verwendet. Als ich schrieb, ich
würde Variante 2 verwenden, meinte ich damit eine Präferenz, aber
nicht, dass die anderen beiden Varianten "falsch" wären oder davon
abzuraten wäre.

> Das wäre wirklich die letzte Version, die mir einfallen würde - nicht nur, weil ich, der ich die Flexibilität der format-Methode praktisch nie benötige, diese selten verwende.

Ich und anscheinend auch andere verwenden `format` mittlerweile
dort, wo sie früher Prozent-Formatierungen verwendet haben. Dann
wird die Verwendung von `format` relativ häufig.

(Mir ist klar, dass man über "`format` oder nicht?" ausgiebig
diskutieren kann und ich gehe davon aus, dass das bei der
Einführung von `format` auch passiert ist.)

> PEP 20.2, "Explicit is better than implicit."
> PEP 20.3, "Simple is better than complex."
> [...]

In meine Präferenz spielen aus PEP 20 mit hinein:

- Readability counts.

Interessant finde ich, dass wir beide "Readability counts" anführen,
aber unterschiedliche Dinge lesbar finden.

- There should be one-- and preferably only one --obvious way to do it.

_Den_ offensichtlichen Weg gibt es hier anscheinend nicht, aber die
Verwendung von `format` ist aus meiner Sicht "the most obvious". Ich
finde, wenn ich drei Strings mit

  "{}+{}-{}".format(a, b, c)

zu einem neuen String kombiniere, sollte der Code nicht ganz anders
aussehen, wenn keine Zeichen dazwischen stehen. Ich denke, hier spielt
hinein, welches Idiom wir in dem Code jeweils sehen - einen String aus
einem Template erzeugen (siehe auch die Mail von Ole) oder eine Reihe
von Strings verketten. Dieses Idiom würde ich eher sehen, wenn die
Strings schon in einer Liste vorliegen.

Wenn es darum geht, möglichst fehlerarmen und lesbaren Code zu
schreiben, ist mein Ansatz, möglichst geradlinigen, "langweiligen"
Code zu schreiben. Ich verwende sehr selten explizite Typ-Prüfungen
und normalerweise würde ich nicht Code extra so schreiben, dass er
möglichst viele implizite Typ-Prüfungen durchführt. Wenn der Code
leicht lesbar ist, ist es wahrscheinlicher, dass Fehler schon beim
Schreiben auffallen beziehungsweise gar nicht erst gemacht werden. Die
Typ-Fehler versuche ich eher, mit automatisierten Tests zu finden.
Aber auch da verwende ich selten _explizite_ Typ-Prüfungen.

Ein damit zusammenhängender Aspekt ist Kontext: Bei meiner Antwort bin
ich (unbewusst) davon ausgegangen, dass in der Praxis die Namen nicht
`a`, `b` und `c` heißen und dass zu erkennen ist, wo die Werte
herkommen. Das reduziert die Wahrscheinlichkeit von falschen Typen
schon mal ganz erheblich, so dass das bei der Wahl des konkreten Codes
kaum noch eine Rolle spielt.

> Ich kann sogar die Lesbar- und auch Änderbarkeit noch auf die Spitze treiben:
>
> d = ''.join([a, # Erklärung des ganz woanders erzeugten Wertes a
> b, # dto. für b
> c, # dto. für c
> ])

Ich bin mir nicht so sicher, ob das den Code wirklich lesbarer macht.
Ich würde eher versuchen, sprechende Bezeichner zu verwenden und die
Funktion/Methode so kurz zu halten, dass auch ohne Kommentare
erkennbar ist, um was für Werte es sich handelt. In extremen Fällen
können zusätzliche Kommentare sinnvoll sein, aber ich finde nicht,
dass der Code damit automatisch lesbarer wird (aber unter Umständen
besser wartbar).

Viele Grüße
Stefan