Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #4860 > unrolled thread

strings zusammensetzen.

Back to article view | Back to de.comp.lang.python

Contents

  strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-25 07:45 +0200
    Re: [Python-de] strings zusammensetzen. Mike Müller <mmueller@python-academy.de> - 2017-08-25 08:00 +0200
    Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-08-25 08:05 +0200
    Re: [Python-de] strings zusammensetzen. Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2017-08-25 09:08 +0200
    Re: [Python-de] strings zusammensetzen. "Tobias Herp" <tobias.herp@gmx.de> - 2017-08-25 10:28 +0200
      Re: [Python-de] strings zusammensetzen. ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2017-08-25 10:47 +0200
        Re: [Python-de] strings zusammensetzen. Tobias Herp <tobias.herp@gmx.de> - 2017-08-25 23:28 +0200
          Re: [Python-de] strings zusammensetzen. ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2017-08-26 10:30 +0200
        Re: [Python-de] strings zusammensetzen. Peter Otten <__peter__@web.de> - 2017-08-26 13:29 +0200
        Re: [Python-de] strings zusammensetzen. "Walter Dörwald" <walter@livinglogic.de> - 2017-08-29 17:21 +0200
          Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-30 07:26 +0200
            Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-08-30 07:48 +0200
              Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-30 08:04 +0200
                Re: [Python-de] strings zusammensetzen. ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2017-08-30 08:23 +0200
                  Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-30 09:37 +0200
                    Re: [Python-de] strings zusammensetzen. Peter Otten <__peter__@web.de> - 2017-08-30 10:23 +0200
                      Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-30 20:00 +0200
                Re: [Python-de] strings zusammensetzen. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2017-08-30 08:30 +0000
                  Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-30 20:03 +0200
                    Re: [Python-de] strings zusammensetzen. Thomas Orgelmacher <trash@odbs.org> - 2017-08-30 20:21 +0200
                      Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-31 14:31 +0200
                        Re: [Python-de] strings zusammensetzen. Thomas Orgelmacher <trash@odbs.org> - 2017-08-31 19:26 +0200
                    Re: [Python-de] strings zusammensetzen. Peter Otten <__peter__@web.de> - 2017-08-30 21:24 +0200
                      Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-08-31 14:40 +0200
                        Re: [Python-de] strings zusammensetzen. Peter Otten <__peter__@web.de> - 2017-08-31 15:26 +0200
                          Re: [Python-de] strings zusammensetzen. "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-16 09:45 +0200
                        Re: [Python-de] strings zusammensetzen. Thomas Orgelmacher <trash@odbs.org> - 2017-08-31 19:11 +0200
                          Re: [Python-de] strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-09-01 09:12 +0200
                            Re: [Python-de] strings zusammensetzen. Thomas Orgelmacher <trash@odbs.org> - 2017-09-01 21:06 +0200
                              Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-09-01 21:43 +0200
                              Re: [Python-de] strings zusammensetzen. Arnold Krille <arnold@arnoldarts.de> - 2017-09-02 15:23 +0200
            Re: [Python-de] strings zusammensetzen. "Walter Dörwald" <walter@livinglogic.de> - 2017-08-30 11:53 +0200
            Re: [Python-de] strings zusammensetzen. Mike Müller <mmueller@python-academy.de> - 2017-08-30 16:14 +0200
    Re: [Python-de] strings zusammensetzen. Mike Müller <mmueller@python-academy.de> - 2017-08-25 11:18 +0200
    Re: [Python-de] strings zusammensetzen. Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2017-08-25 12:40 +0200
    Re: [Python-de] strings zusammensetzen. Tobias Herp <tobias.herp@gmx.de> - 2017-08-25 23:41 +0200
    Re: [Python-de] strings zusammensetzen. "Dr. Volker Jaenisch" <volker.jaenisch@inqbus.de> - 2017-08-26 02:34 +0200
    Re: strings zusammensetzen. Thomas Orgelmacher <trash@odbs.org> - 2017-08-29 19:05 +0200
      Re: strings zusammensetzen. ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2017-08-30 08:32 +0200
      Re: strings zusammensetzen. "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-16 09:28 +0200
        Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-09-16 10:33 +0200
          Re: [Python-de] strings zusammensetzen. "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-16 22:46 +0200
            Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-09-17 08:19 +0200
              Re: [Python-de] strings zusammensetzen. "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-17 12:34 +0200
            Re: [Python-de] strings zusammensetzen. ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2017-09-17 10:50 +0200
              Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-09-17 11:14 +0200
              Re: [Python-de] strings zusammensetzen. "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-17 14:19 +0200
        Re: strings zusammensetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-09-16 16:19 +0200
          Re: [Python-de] strings zusammensetzen. Stefan Behnel <python-de@behnel.de> - 2017-09-16 17:30 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#4909 — Re: [Python-de] strings zusammensetzen.

Peter J. Holzer schrieb am 16.09.2017 um 09:28:
> (String-Konkatenation ist in Python(3) zumindest bei langen Strings auch
> schön linear)

Es gibt sowohl für bytes-Objekte als auch für Unicode-Strings eine
Sonderbehandlung, die realloc() verwendet. Auf vielen Platformen ist
realloc() effizient und führt im Durchschnitt zu einer linearen Laufzeit
auch bei mehreren Konkatenierungen. Aber nicht auf allen.

Außerdem greift die Optimierung nicht in allen Fällen. Beispielsweise hast
du Pech, wenn über die Konkatenierungen hinweg der Zeichenraum erst von
ASCII auf BMP und dann auf Astral wechselt. Dann muss beim Wechsel der
komplette bisherige String doch wieder im Speicher herum kopiert werden.
Ein join() kann das vermeiden, weil gleich am Anfang alle Strings bekannt
sind, und damit auch der finale Zeichenraum. Hier hast du also die
Garantie, dass das Zusammenfügen effizient erfolgt.

Also kurz: join() ist in jedem Fall die bessere Variante bei vielen
Strings. Konkatenierung ist ok bei einer überschaubaren Menge und da
insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden werden.

Stefan

[toc] | [prev] | [next] | [standalone]

#4912 — Re: [Python-de] strings zusammensetzen.

On 2017-09-16 08:33, Stefan Behnel <python-de@behnel.de> wrote:
> Peter J. Holzer schrieb am 16.09.2017 um 09:28:
>> (String-Konkatenation ist in Python(3) zumindest bei langen Strings auch
>> schön linear)
>
> Es gibt sowohl für bytes-Objekte als auch für Unicode-Strings eine
> Sonderbehandlung, die realloc() verwendet. Auf vielen Platformen ist
> realloc() effizient und führt im Durchschnitt zu einer linearen Laufzeit
> auch bei mehreren Konkatenierungen. Aber nicht auf allen.

Ineffiziente Plattformen sollte man meiden :-). Allerdings ist das eher
eine Frage, wie Python damit umgeht als wie gut die Malloc-
Implementation ist - obwohl eine gute Malloc-Implementation gewisse
Schwächen im Interpreter gut übertünchen kann (wie eine Diskussion zum
gleichen Thema in Perl vor ein paar Jahren gezeigt hat).


> Außerdem greift die Optimierung nicht in allen Fällen. Beispielsweise hast
> du Pech, wenn über die Konkatenierungen hinweg der Zeichenraum erst von
> ASCII auf BMP und dann auf Astral wechselt. Dann muss beim Wechsel der
> komplette bisherige String doch wieder im Speicher herum kopiert werden.

Das dürfte weitgehend vernachlässigbar sein, weil es maximal 2 solche
Übergänge geben kann. Also viel weniger als die Kopiervorgänge, die
üblicherweise tatsächlich stattfinden, weil realloc nicht in-place
expandieren kann.

> Also kurz: join() ist in jedem Fall die bessere Variante bei vielen
> Strings. Konkatenierung ist ok bei einer überschaubaren Menge und da
> insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden werden.

Du vergisst, dass Listen einen nicht zu vernachlässigbaren
Memory-Overhead haben. Gerade bei langen Listen sollte man darauf
verzichten, sie aufzubauen, wenn man sie nicht unbedingt braucht (habe
damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl und
nicht Python, aber die beiden Sprachen sind sich da sehr ähnlich)).

Kleiner Test:

------------------------------------------------------------------------
#!/usr/bin/python3

import sys
import time

n = int(sys.argv[1])
t0 = time.clock_gettime(time.CLOCK_MONOTONIC)

s = ""
for i in range(n):
    s += str(i)

t1 = time.clock_gettime(time.CLOCK_MONOTONIC)
print(n, t1-t0, n / (t1 - t0))
------------------------------------------------------------------------

------------------------------------------------------------------------
#!/usr/bin/python3

import sys
import time

n = int(sys.argv[1])

tick_size = 1000000
t0 = time.clock_gettime(time.CLOCK_MONOTONIC)

elems = []
for i in range(n):
    elems.append(str(i))
s = "".join(elems)

t1 = time.clock_gettime(time.CLOCK_MONOTONIC)
print(n, t1 - t0, n / (t1 - t0))
------------------------------------------------------------------------

Ergebnis: Performance ist praktisch gleich, aber auf einer
32-Bit-Maschine kommt die Konkatenierungsversion gut 3 mal so weit,
bevor sie am Memory-Limit anstößt.

(Graphik auf <http://www.hjp.at/programming/python/concat-vs-join/>)

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#4913 — Re: [Python-de] strings zusammensetzen.

Peter J. Holzer schrieb am 16.09.2017 um 22:46:
> Gerade bei langen Listen sollte man darauf
> verzichten, sie aufzubauen, wenn man sie nicht unbedingt braucht

Natürlich. Einzig darauf zielt dein Beispielcode ja auch ab.

Gilt übrigens genauso für lange Strings.


> (habe
> damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl und
> nicht Python, aber die beiden Sprachen sind sich da sehr ähnlich)).

Wie du hier korrekt andeutest, handelt es sich bei dem gegebenen Fall um
eine Optimierung. Optimierung bedeutet ja, dass du eigentlich gut
geschriebenen Code ersetzt durch etwas, was dem spezifischen Anwendungsfall
stärker angepasst ist und (nachweislich) unter den erwarteten Bedingungen
effizienter funktioniert. Mit dem Risiko, dass es unter anderen (eben nicht
erwarteten) Bedingungen vielleicht auch weniger gut funktioniert. Kann
manchmal zu Y2K-Problemen führen, aber ansonsten ist dagegen nichts
einzuwenden.

Stefan

[toc] | [prev] | [next] | [standalone]

#4916 — Re: [Python-de] strings zusammensetzen.

On 2017-09-17 06:19, Stefan Behnel <python-de@behnel.de> wrote:
> Peter J. Holzer schrieb am 16.09.2017 um 22:46:
>> Gerade bei langen Listen sollte man darauf verzichten, sie
>> aufzubauen, wenn man sie nicht unbedingt braucht
>
> Natürlich. Einzig darauf zielt dein Beispielcode ja auch ab.
>
> Gilt übrigens genauso für lange Strings.

Natürlich. Wenn man den langen String nie braucht, soll man ihn auch
nicht aufbauen. Gerade, wenn der String an einen Konsumenten geschickt
werden soll, der ihn dann gleich wieder parst, hat man auch noch den
Vorteil, dass Produzent und Konsument sich zeitlich überlappen können,
wenn der Produzent Teile des Outputs so früh wie möglich schickt. Geht
aber leider nicht immer: Manche Protokolle brauchen z.B. eine
Längenangabe im Header und dafür muss man den Output erst mal komplett
haben, um die Länge bestimmen zu können.

>> (habe damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl
>> und nicht Python, aber die beiden Sprachen sind sich da sehr
>> ähnlich)).
>
> Wie du hier korrekt andeutest, handelt es sich bei dem gegebenen Fall um
> eine Optimierung. Optimierung bedeutet ja, dass du eigentlich gut
> geschriebenen Code ersetzt durch etwas, was dem spezifischen Anwendungsfall
> stärker angepasst ist und (nachweislich) unter den erwarteten Bedingungen
> effizienter funktioniert. Mit dem Risiko, dass es unter anderen (eben nicht
> erwarteten) Bedingungen vielleicht auch weniger gut funktioniert.

Richtig. Wobei in diesem Fall allerdings beide Varianten von der
Code-Länge und Lesbarkeit her ziemlich vergleichbar waren. Im Gegensatz
zu manchen anderen Fällen, wo es klar eine "saubere" und eine optimierte
Variante gibt, gab es hier zwei Varianten, die zwar verschiedenen
Ansätzen (eher prozedural und eher funktional) folgten, aber (für meinen
Geschmack) beide gleich sauber waren. Da dann die Variante zu wählen,
die weniger Speicher braucht und schneller ist, ist ein No-Brainer (und
ja, ich habe beide Varianten gebenchmarkt, bevor ich die Änderung
durchgeführt habe).

Bei dem kleinen Test-Programm sehe ich das ähnlich: Die Variante mit
join ist *nicht* klar sauberer. Eher im Gegenteil: Sie baut explizit
eine unnötige Datenstruktur auf, das empfinde ich als unelegant. (Etwas
anderes ist es, wenn die Datenstruktur nur implizit aufgebaut wird: Mit
map statt der explizitien Schleife (was bei diesem Trivialbeispiel
natürlich leicht möglich gewesen wäre) wäre der Code für mich eindeutig
eleganter und damit wäre eine möglich Optimierung nur sinnvoll, wenn die
positiven Effekte zur Laufzeit die negativen Effekte für den
Programmierer überwiegen.)

Aber im wesentlichen ging es mir eben um Deine dogmatisch vorgetragene
Aussage:

| join() ist in jedem Fall die bessere Variante bei vielen Strings.

Das sehe ich eben nicht so. Gerade bei vielen Strings gibt es Fälle, wo
es besser ist, den String stückweise in einer Schleife aufzubauen.

| Konkatenierung ist ok bei einer überschaubaren Menge und da
| insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden
| werden.

Und wie nun ausführlich begründet, sehe ich das genau umgekehrt: Bei
kurzen Strings, die aus wenigek Komponenten zusammengesetzt werden, ist
beides Ok. Bei langen Strings, die aus vielen Komponenten aufgebaut
werden, sollte man sich überlegen, ob nicht eine explizite Schleife
besser ist als ein Join.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#4914 — Re: [Python-de] strings zusammensetzen.

"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> elems = []
> for i in range(n):
>     elems.append(str(i))
> s = "".join(elems)

Wenn Du hier schon auf Optimierung achtest: wozu dann erst lie Liste?
Join nimmt jedes Iterable:

s = "".join(map(str, range(x)))

Ist kürzer, prägnanter, performanter und deutlich effektiver im
Speicher.

Letztlich ist es (wie immer) stark von der Aufgabenstellung abhängig:
häufig hat man (wenn man denn einen großen String bauen will) gar keine
Strings als Ausgangsbasis, sondern etwas anderes. Und da macht es keinen
Sinn, temporär Listen von Strings zu erzeugen, sondern man sollte lieber
mit Iterables arbeiten, die man mappt.

Ole

[toc] | [prev] | [next] | [standalone]

#4915 — Re: [Python-de] strings zusammensetzen.

Оlе Ѕtrеісhеr schrieb am 17.09.2017 um 10:50:
> "Peter J. Holzer" writes:
>> elems = []
>> for i in range(n):
>>     elems.append(str(i))
>> s = "".join(elems)
> 
> Wenn Du hier schon auf Optimierung achtest: wozu dann erst lie Liste?
> Join nimmt jedes Iterable:
> 
> s = "".join(map(str, range(x)))
> 
> Ist kürzer, prägnanter, performanter und deutlich effektiver im
> Speicher.

Bezüglich "effektiver im Speicher" möchte ich anregen, den Code zu lesen.
Intern erzeugt "".join(genexpr) zuerst eine Liste. Das passiert immer, wenn
keine Sequenz übergeben wird. Schließlich muss zweimal über diese drüber
gelaufen werden können, was bei Iteratoren nicht gegeben ist.

Ein Eckchen schneller wird map() hier wohl trotzdem sein, aber wir sollten
nicht vergessen, dass so etwas wie das Beispiel oben in der Praxis nur
*sehr* selten auftreten dürfte.

Stefan

[toc] | [prev] | [next] | [standalone]

#4918 — Re: [Python-de] strings zusammensetzen.

On 2017-09-17 08:50, Оlе Ѕtrеісhеr <ole-usenet-spam@gmx.net> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> elems = []
>> for i in range(n):
>>     elems.append(str(i))
>> s = "".join(elems)
>
> Wenn Du hier schon auf Optimierung achtest: wozu dann erst lie Liste?

Weil das einer der beiden Fälle war, die ich miteinander vergleichen
wollte. Und natürlich ist das ein Test-Beispiel und nichts, was so in
Produktivcode irgendwo vorkommt.


> Join nimmt jedes Iterable:
>
> s = "".join(map(str, range(x)))
>
> Ist kürzer, prägnanter,

Ja, definitiv. Aber es ist eine Änderung, die für den Vergleich
irrelevant ist und daher den Leser vom Kern des Arguments ablenken
würde. Daher habe ich das unterlassen.

> performanter

Bei diesem trivialen Test-Beispiel: Ja. Wenn die Schleife etwas mehr
macht als nur "str" aufzurufen, dürfte der Performance-Unterschied
zwischen map und einer expliziten Schleife eher vernachlässigbar sein.

> und deutlich effektiver im Speicher.

Nein. Ob die Liste implizit von join aufgebaut wird oder explizit vom
Programmcode, macht keinen Unterschied.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#4910

Am 16.09.2017 um 09:28 schrieb Peter J. Holzer:

 > Wenn Du die bereits in einer Liste vorliegen hast, ist "".join(liste)
 > natürlich ideal.

 > Aber wenn Du die Liste erst bauen musst, ist

 >      liste = []
 >      for ...:
 >          element = ...
 >          liste.append(element)
 >      s = "".join(liste)

 > sicher nicht besser als

 >      s = ""
 >      for ...:
 >          element = ...
 >          s += element
Wenn bei einer Liste ein Element angehängt wird werden vermutlich
nur eine 4 oder 8 byte lange Adresse in ein Feld angehängt.
Bei jedem Buchstabe je nach utf-darstellung 2 oder 4 byte.
( Bei diakritischen Zeichen entsprechend mehr)

Wenn bei Speicherplatz eines Feldes nicht bei jeden neuen
Element ein neues Feld angelegt wird,
sondern bei Erweiterungen hinten vielleicht 20% Platz
für Erweiterungen reserviert werden,
dürfte es einiges schneller gehen.

 > (String-Konkatenation ist in Python(3)
 > zumindest bei langen Strings auch schön linear)

In Python2 war jeder Buchstabe 1 byte;
utf- Sonderzeichen wie ö Zeichen waren halt mehrere Buchstaben.
( Diakritische Zeichen sind auch in Python3 "mehr als ein Buchstabe"
   was z.B. bei Indizierung, Zerlegung etc.
   unerwartete Effekte haben kann.)

Hermann
    der nicht sagen kann, ob für strings mit gleichem Inhalt
    jedes mal neuer Speicherplatz angelegt wird,
    oder eine hash Suche losläuft.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#4911 — Re: [Python-de] strings zusammensetzen.

Hermann Riemann schrieb am 16.09.2017 um 16:19:
> Wenn bei einer Liste ein Element angehängt wird werden vermutlich
> nur eine 4 oder 8 byte lange Adresse in ein Feld angehängt.
> Bei jedem Buchstabe je nach utf-darstellung 2 oder 4 byte.
> ( Bei diakritischen Zeichen entsprechend mehr)

In Py2 gab es die 2-byte Unicode-Option, die wirklich UTF-16 verwendet hat
(war vor allem unter Windows verbreitet), aber in Py3 ist die interne
Darstellung nicht UTF-kodiert, sondern es wird zwischen ASCII, ISO8859-1,
BMP und Astral unterschieden. In einzelnen Sonderfällen gibt es auch da
noch eine UTF-16 Darstellung, aber die wird praktisch (außerhalb der
Windows-Welt) nicht mehr verwendet. Kannst sie als Implementierungsdetail
ansehen.


> Wenn bei Speicherplatz eines Feldes nicht bei jeden neuen
> Element ein neues Feld angelegt wird,
> sondern bei Erweiterungen hinten vielleicht 20% Platz
> für Erweiterungen reserviert werden,
> dürfte es einiges schneller gehen.

Ist bei Listen so, genau aus dem Grund. Wenn einmal was angehängt wird, war
mit mit sehr hoher Wahrscheinlichkeit nicht das letzte Mal.


> In Python2 war jeder Buchstabe 1 byte;

Blödsinn.


> utf- Sonderzeichen wie ö Zeichen waren halt mehrere Buchstaben.

Blödsinn.


> ( Diakritische Zeichen sind auch in Python3 "mehr als ein Buchstabe"
>   was z.B. bei Indizierung, Zerlegung etc.
>   unerwartete Effekte haben kann.)

Richtig. Da hilft in den meisten Fällen eine Zeichennormalisierung. Oft
genug ist es aber auch einfach egal, weil Text überraschend oft gar nicht
zeichenweise verarbeitet wird.


> Hermann
>    der nicht sagen kann, ob für strings mit gleichem Inhalt
>    jedes mal neuer Speicherplatz angelegt wird,
>    oder eine hash Suche losläuft.

Code lesen hilft.

Stefan

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | de.comp.lang.python

csiph-web