Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Tobias Herp" <tobias.herp@gmx.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] strings zusammensetzen.
Date: Fri, 25 Aug 2017 10:28:53 +0200
Lines: 86
Message-ID: <mailman.225.1503650044.2689.python-de@python.org>
References: <f09rraFsnvuU1@mid.individual.net> <ef71e437-bbc6-7e50-73ad-3399c683ac29@sschwarzer.net> <trinity-ecb4b23f-0a85-47e0-a1db-ad5f32564d29-1503649732983@3c-app-gmx-bs49>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: normal
Sensitivity: Normal
In-Reply-To: <ef71e437-bbc6-7e50-73ad-3399c683ac29@sschwarzer.net>
Precedence: list
Xref: csiph.com de.comp.lang.python:4864

>> a b und c enthalten strings=2E
>>
>> d=3Da+b+c besser als # Variante 1
>> d=3D"{}{}{}"=2Eformat(a,b,c) ? # Variante 2

>Die zweite Variante ist das =C3=BCbliche Idiom, wenn es um die Kombinatio=
n
>von Strings geht=2E

Wirklich? Himmel hilf!
Das w=C3=A4re wirklich die letzte Version, die mir einfallen w=C3=BCrde - =
nicht nur, weil ich, der ich die Flexibilit=C3=A4t der format-Methode prakt=
isch nie ben=C3=B6tige, diese selten verwende=2E

PEP 20=2E2, "Explicit is better than implicit=2E"
PEP 20=2E3, "Simple is better than complex=2E"

Wenn ich drei Variablen habe, von denen ich wei=C3=9F, da=C3=9F es Strings=
 sind, verwende ich keinen Code, der auch beliebigen anderen Input stillsch=
weigend (implizit) konvertiert=2E
Wenn ich addieren will, addiere ich=2E
Von daher spricht nichts gegen Variante 1:

d =3D a + b + c

PEP 20=2E7, "Readability counts=2E"

Variante 1 ist prima lesbar, aber m=C3=B6glicherweise besteht tats=C3=A4ch=
lich ds Bed=C3=BCrfnis, dem Leser zu "beweisen", da=C3=9F das Ergebnis ein =
String ist=2E
Dann erf=C3=BCllt die "Variante 3" den Zweck:

d =3D ''=2Ejoin([a, b, c])

(die sich auch immer f=C3=BCr inkrementell zusammengebaute Strings anbiete=
t)=2E
Sie hat den weiteren Vorteil, da=C3=9F sie fehlschl=C3=A4gt, wenn eine der=
 Eingabevariablen kein String ist:

PEP 20=2E10, "Errors should never pass silently=2E"

Ich kann sogar die Lesbar- und auch =C3=84nderbarkeit noch auf die Spitze =
treiben:

d =3D ''=2Ejoin([a, # Erkl=C3=A4rung des ganz woanders erzeugten Wertes a
b, # dto=2E f=C3=BCr b
c, # dto=2E f=C3=BCr c
])

Dies ist sehr leicht =C3=A4nderbar, wenn ein Element hinzukommt, ge=C3=A4n=
dert wird oder entf=C3=A4llt=2E Vergleichs-Tools arbeiten zeilenorientiert=
=2E

Die "Variante 3" konvertiert Nicht-Strings stillschweigend=2E Was aber, we=
nn ich ganz selbstverst=C3=A4ndlich davon ausgehe, da=C3=9F es Strings sind=
, und eine Abweichung hiervon ein sicheres Zeichen f=C3=BCr einen Fehler is=
t? Ich verplempere nicht nur eine Menge Rechenzeit, sondern verberge auch n=
och den Fehler:

PEP 20=2E10, "Errors should never pass silently=2E"

Wenn ich die implizite String-Konversion will, kann ich das auch so erreic=
hen:

d =3D ''=2Ejoin(map(str, [a, b, c]))

Damit weise ich darauf hin, da=C3=9F ich damit rechne, da=C3=9F die Eingab=
ewerte m=C3=B6glicherweise keine Strings sind, aber in solche konvertiert w=
erden k=C3=B6nnen:

PEP 20=2E11, "Unless explicitly silenced=2E"

Schlu=C3=9Fendlich hat Variante 2 noch einen weiteren Nachteil: sie ist um=
st=C3=A4ndlich zu =C3=A4ndern=2E
Wenn sich die Anzahl der zu verkettenden Strings =C3=A4ndert, mu=C3=9F sow=
ohl ein "{}" hinzugef=C3=BCgt oder gel=C3=B6scht *als auch* die eigentliche=
 =C3=84nderung vorgenommen werden=2E
Bei drei Argumenten mag das gerade noch vertretbar sein; aber schon bei we=
nig mehr f=C3=A4ngt die Z=C3=A4hlerei an=2E

Also, ganz eindeutig: Variante 1 oder 3, aber keinesfalls 2=2E

--
Sch=C3=B6nen Gru=C3=9F,

Tobias