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 23:28:03 +0200
Lines: 111
Message-ID: <mailman.239.1503696106.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> <mailman.225.1503650044.2689.python-de@python.org> <ytz1so08253.fsf@news.ole.ath.cx> <40c6ccec-4cbc-9614-dbdd-9e88cd1dccf0@gmx.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ioOU26cFMDjxA6HXG9WTIDgMnmFahHcWg"
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
In-Reply-To: <ytz1so08253.fsf@news.ole.ath.cx>
Precedence: list
Xref: csiph.com de.comp.lang.python:4868

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ioOU26cFMDjxA6HXG9WTIDgMnmFahHcWg
Content-Type: multipart/mixed; boundary="MHFBunA9RNiGFFFNjN2OxefOmgnc3TQig";
 protected-headers="v1"
From: Tobias Herp <tobias.herp@gmx.de>
To: =?UTF-8?B?0J5s0LUg0IV0ctC10ZbRgWjQtXI=?= <ole-usenet-10@gmx.net>,
 python-de@python.org
Message-ID: <40c6ccec-4cbc-9614-dbdd-9e88cd1dccf0@gmx.de>
Subject: Re: [Python-de] strings zusammensetzen.
References: <f09rraFsnvuU1@mid.individual.net>
 <ef71e437-bbc6-7e50-73ad-3399c683ac29@sschwarzer.net>
 <trinity-ecb4b23f-0a85-47e0-a1db-ad5f32564d29-1503649732983@3c-app-gmx-bs49>
 <mailman.225.1503650044.2689.python-de@python.org>
 <ytz1so08253.fsf@news.ole.ath.cx>
In-Reply-To: <ytz1so08253.fsf@news.ole.ath.cx>

--MHFBunA9RNiGFFFNjN2OxefOmgnc3TQig
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=D0=9El=D0=B5 =D0=85tr=D0=B5=D1=96=D1=81h=D0=B5r schrieb am 25.08.2017 um=
 10:47:
> "Tobias Herp" <tobias.herp@gmx.de> writes:
>>>> a b und c enthalten strings.
>>>>
>>>> d=3Da+b+c besser als # Variante 1
>>>> d=3D"{}{}{}".format(a,b,c) ? # Variante 2
>>
>>> Die zweite Variante ist das =C3=BCbliche Idiom, wenn es um die Kombin=
ation
>>> von Strings geht.
>>
>> Wirklich? Himmel hilf!
>=20
> Das h=C3=A4ngt IMO stark vom Use-Case ab. Oft hat man z.B. solche
> String-Concatenierungen im Zusammenhang mit der Erstellung von
> Dateinamen. Und da w=C3=A4re es besser, ein Template zu verwenden -- ge=
nau im
> Sinne von "explizit ist besser als implizit":

Nur dadurch, da=C3=9F etwas umst=C3=A4ndlich programmiert ist, wird es no=
ch nicht
expliziter.  Und umst=C3=A4ndlich ist es, wenn man zum Hinzuf=C3=BCgen ei=
ner
weiteren Variablen zwei =C3=84nderungen vornehmen mu=C3=9F.

Es sollte jedenfalls nicht die Antwort auf die Frage sein, wie man in
Python Strings verkettet.  Das ist ja schlimmer als die
concat-Funktionen anderen Sprachen!

> d =3D "{base}{revision}{suffix}".format(base =3D a,=20
>                                       revision =3D b,
>                                       suffix =3D c)

Wenn's denn unbedingt ein Template sein soll, w=C3=BCrde das bei mir meis=
tens
wie folgt aussehen:

d =3D '%(base)s%(revision)s%(suffix)s' % locals()

(nat=C3=BCrlich nennt *niemand* seine Variablen a, b und c, bzw. w=C3=BCr=
de es
nach Lekt=C3=BCre dieses Threads niemals zugeben...)

Im =C3=BCbrigen kann es nat=C3=BCrlich jedem St=C3=BCck Code in einem gr=C3=
=B6=C3=9Feren Projekt
(oder in einer Server-Anwendung) passieren, da=C3=9F es sehr oft durchlau=
fen
wird.  Und sp=C3=A4testens dann spielt die Performanz eine Rolle.  Die
=2Eformat-Methode bezahlt f=C3=BCr ihre (ich behaupte: in mindestens 95% =
der
F=C3=A4lle nicht ben=C3=B6tigte) zus=C3=A4tzliche Flexibilit=C3=A4t mit s=
ehr viel
schlechterer Performanz.

> Allgemein w=C3=BCrde ich, wenn es sich um Strings handelt, immer genau
> schauen, ob man nicht eigentlich ein Template f=C3=BCllen m=C3=B6chte, =
das nur
> gerade zuf=C3=A4llig sehr einfach ausf=C3=A4llt.

Man kann es auch =C3=BCbertreiben mit der vorausschauenden Komplexit=C3=A4=
t.
Wie hei=C3=9Ft es doch so sch=C3=B6n - YAGNI!
You ain't gonna need it!

Sch=C3=B6nenn Gru=C3=9F,

Tobias
--=20
Ceterum censeo:
Etwaige .sig-Dateien brauchen nicht ge=C3=B6ffnet zu werden!
Siehe <http://www.gnupg.org/>, <http://enigmail.mozdev.org/>


--MHFBunA9RNiGFFFNjN2OxefOmgnc3TQig--

--ioOU26cFMDjxA6HXG9WTIDgMnmFahHcWg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlmglm0ACgkQM/sLV1LEeIqKLQCfaeHiWoZMopMc2E7aueVewOr8
OgEAniUtcFtKzXyqDgpIELDemHYF1GSI
=MVPo
-----END PGP SIGNATURE-----

--ioOU26cFMDjxA6HXG9WTIDgMnmFahHcWg--