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 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

Am 30.08.2017 um 20:21 schrieb Thomas Orgelmacher:

>> Bei Risiko halt:
>> os.system('rm "'+dateiname+'"')

> Wozu? Das bringt Dir lediglich einen zusätzlichen fork mit einem
> execve in die Shell, die dann rm ausführt (WIMRE ein weiterer fork).

> Die genannte Alternative "kostet" Dich lediglich einen Syscall und
> damit einen Bruchteil von os.system().

Wenn ich die Zeit vom Nachschlagen im Python3 Buch
mit einrechne, sieht es anders aus.

Hermann
    der auch über den Umweg codecs.open und io.open
    mit Ausnahme von cgi wieder zu open
    zurückgekehrt ist.

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

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

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

Am 31.08.2017 um 14:31 schrieb Hermann Riemann:
> 
[...]
> Wenn ich die Zeit vom Nachschlagen im Python3 Buch
> mit einrechne, sieht es anders aus.

Oh, ok. Dann bastel mal weiter.

Hermann, ich habe noch bei niemandem eine derartig ausgeprägte
"Best-Practices" Allergie gesehen, wie bei dir.


Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

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

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

Hermann Riemann wrote:

> Am 30.08.2017 um 10:30 schrieb Peter Heitzer:
> 
>>>     der wegen des Lernaufwandes und Manual Suchens
>>>     lieber  os.system("rm "+dateiname)
>>>     als os.unlink(dateiname) verwendet.
>> os.unlink() dürfte aber portabler sein und auch mit Leerzeichen und
>> anderen speziellen Zeichen in dateiname zurechtkommen. Wer weiss, was
>> die Shell so treibt.
> 
> Bei Risisko halt:
> os.system('rm "'+dateiname+'"')

Das nützt nix. Sobald Dritte den Dateinamen bestimmen können, bekommst du 
Probleme:

$ cat demo.py
import glob
import os

for filename in os.listdir():
    if not filename.endswith(".py"):
        print("removing", repr(filename))
        os.system("rm '" + filename + "'")
$ touch foo\'\ -f\;echo\ \'oops
$ python3 demo.py
removing "foo' -f;echo 'oops"
oops
$ 

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

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

Am 30.08.2017 um 21:24 schrieb Peter Otten:

>>>>      der wegen des Lernaufwandes und Manual Suchens
>>>>      lieber  os.system("rm "+dateiname)
>>>>      als os.unlink(dateiname) verwendet.
>>> os.unlink() dürfte aber portabler sein und auch mit Leerzeichen und
>>> anderen speziellen Zeichen in dateiname zurechtkommen. Wer weiss, was
>>> die Shell so treibt.

>> Bei Risisko halt:
>> os.system('rm "'+dateiname+'"')

> Das nützt nix. Sobald Dritte den Dateinamen bestimmen können, bekommst du
> Probleme:

> $ cat demo.py
> import glob
> import os
> 
> for filename in os.listdir():
>      if not filename.endswith(".py"):
>          print("removing", repr(filename))
>          os.system("rm '" + filename + "'")
> $ touch foo\'\ -f\;echo\ \'oops
> $ python3 demo.py
> removing "foo' -f;echo 'oops"
> oops
> $

ok.

Allerdings fällt mir bei der Gelegenheit ein,
was ist, wenn der Dateiname ein bytestring ist,
der sich nicht nach utf konvertieren lässt?
In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.

Hermann
    der bisher bytestring lediglich zum
    Vergleich von Dateiinhalten verwendet hat.

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

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

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

Hermann Riemann wrote:

> Allerdings fällt mir bei der Gelegenheit ein,
> was ist, wenn der Dateiname ein bytestring ist,
> der sich nicht nach utf konvertieren lässt?
> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.

Unter Linux kein Problem:

>>> import os
>>> ord("/")
47
>>> filename = bytes(c for c in range(1, 256) if c != 47)
>>> filename
b'\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f 
!"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
>>> os.path.exists(filename)
False
>>> with open(filename, "w") as f: f.write("yadda\n")
... 
6
>>> os.path.exists(filename)
True
>>> os.listdir()
['\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f 
!"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\udc80\udc81\udc82\udc83\udc84\udc85\udc86\udc87\udc88\udc89\udc8a\udc8b\udc8c\udc8d\udc8e\udc8f\udc90\udc91\udc92\udc93\udc94\udc95\udc96\udc97\udc98\udc99\udc9a\udc9b\udc9c\udc9d\udc9e\udc9f\udca0\udca1\udca2\udca3\udca4\udca5\udca6\udca7\udca8\udca9\udcaa\udcab\udcac\udcad\udcae\udcaf\udcb0\udcb1\udcb2\udcb3\udcb4\udcb5\udcb6\udcb7\udcb8\udcb9\udcba\udcbb\udcbc\udcbd\udcbe\udcbf\udcc0\udcc1\udcc2\udcc3\udcc4\udcc5\udcc6\udcc7\udcc8\udcc9\udcca\udccb\udccc\udccd\udcce\udccf\udcd0\udcd1\udcd2\udcd3\udcd4\udcd5\udcd6\udcd7\udcd8\udcd9\udcda\udcdb\udcdc\udcdd\udcde\udcdf\udce0\udce1\udce2\udce3\udce4\udce5\udce6\udce7\udce8\udce9\udcea\udceb\udcec\udced\udcee\udcef\udcf0\udcf1\udcf2\udcf3\udcf4\udcf5\udcf6\udcf7\udcf8\udcf9\udcfa\udcfb\udcfc\udcfd\udcfe\udcff']

Hier sieht man, was mit nicht dekodierbaren Bytes geschieht -- Python 
verwendet den surrogate-escape error handler:

>>> b"\xf1\xf2\xf3".decode("utf-8", "surrogateescape")
'\udcf1\udcf2\udcf3'
>>>

Die Shell kann da nicht mithalten:

[2]+  Angehalten              python3
$ ls
??????????????????????????????? 
!"#$%&'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
$ fg
python3


>>> os.remove(filename)
>>> os.listdir()
[]

Unter Windows sind die Regeln wohl etwas komplexer.

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

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

On 2017-08-31 13:26, Peter Otten <__peter__@web.de> wrote:
> Hermann Riemann wrote:
>
>> Allerdings fällt mir bei der Gelegenheit ein,
>> was ist, wenn der Dateiname ein bytestring ist,
>> der sich nicht nach utf konvertieren lässt?
>> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.
>
> Unter Linux kein Problem:
>
>>>> import os
>>>> ord("/")
> 47
>>>> filename = bytes(c for c in range(1, 256) if c != 47)
>>>> filename
> b'\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f 
> !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'
>>>> os.path.exists(filename)
> False
>>>> with open(filename, "w") as f: f.write("yadda\n")
> ... 
> 6
>>>> os.path.exists(filename)
> True
>>>> os.listdir()
> ['\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f 
> !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\udc80\udc81\udc82\udc83\udc84\udc85\udc86\udc87\udc88\udc89\udc8a\udc8b\udc8c\udc8d\udc8e\udc8f\udc90\udc91\udc92\udc93\udc94\udc95\udc96\udc97\udc98\udc99\udc9a\udc9b\udc9c\udc9d\udc9e\udc9f\udca0\udca1\udca2\udca3\udca4\udca5\udca6\udca7\udca8\udca9\udcaa\udcab\udcac\udcad\udcae\udcaf\udcb0\udcb1\udcb2\udcb3\udcb4\udcb5\udcb6\udcb7\udcb8\udcb9\udcba\udcbb\udcbc\udcbd\udcbe\udcbf\udcc0\udcc1\udcc2\udcc3\udcc4\udcc5\udcc6\udcc7\udcc8\udcc9\udcca\udccb\udccc\udccd\udcce\udccf\udcd0\udcd1\udcd2\udcd3\udcd4\udcd5\udcd6\udcd7\udcd8\udcd9\udcda\udcdb\udcdc\udcdd\udcde\udcdf\udce0\udce1\udce2\udce3\udce4\udce5\udce6\udce7\udce8\udce9\udcea\udceb\udcec\udced\udcee\udcef\udcf0\udcf1\udcf2\udcf3\udcf4\udcf5\udcf6\udcf7\udcf8\udcf9\udcfa\udcfb\udcfc\udcfd\udcfe\udcff']
>
> Hier sieht man, was mit nicht dekodierbaren Bytes geschieht -- Python 
> verwendet den surrogate-escape error handler:
>
>>>> b"\xf1\xf2\xf3".decode("utf-8", "surrogateescape")
> '\udcf1\udcf2\udcf3'
>>>>
>
> Die Shell kann da nicht mithalten:
>
> [2]+  Angehalten              python3
> $ ls
> ??????????????????????????????? 
> !"#$%&'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Die Shell ist da gar nicht beteiligt. Die ruft ja nur "ls" auf. Der
Output, den Du da zitierst, stammt von ls, und das ersetzt per default
in der Ausgabe nicht-druckbare Zeichen durch "?" (das ist ein Feature -
man will in einem Terminal nicht, das ls irgendwelche Escape-Codes
ausgeben kann, nur weil der Ersteller eines Files lustig war). Es gibt
Optionen, um die Ausgabe zu ändern, z.B. auf (oktale) Escape-Codes:

% ls -b 
\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\ !"#$%&'()*+,-.0123456789:;<\=\>?\@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{\|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377

Die Shell (zumindest die zsh, und ich nehme an, die bash auch nicht),
hat kein Problem mit solchen Filenamen:

% rm $'\001'$'\002'$'\003'$'\004'$'\005'$'\006'$'\a'$'\b'$'\t'$'\n'$'\v'$'\f'$'\r'$'\016'$'\017'$'\020'$'\021'$'\022'$'\023'$'\024'$'\025'$'\026'$'\027'$'\030'$'\031'$'\032'$'\033'$'\034'$'\035'$'\036'$'\037'\ \!\"\#\$%\&\'\(\)\*+,-.0123456789:\;\<=\>\?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\[\\\]\^_\`abcdefghijklmnopqrstuvwxyz\{\|\}\~$'\177'$'\200'$'\201'$'\202'$'\203'$'\204'$'\205'$'\206'$'\207'$'\210'$'\211'$'\212'$'\213'$'\214'$'\215'$'\216'$'\217'$'\220'$'\221'$'\222'$'\223'$'\224'$'\225'$'\226'$'\227'$'\230'$'\231'$'\232'$'\233'$'\234'$'\235'$'\236'$'\237'$'\240'$'\241'$'\242'$'\243'$'\244'$'\245'$'\246'$'\247'$'\250'$'\251'$'\252'$'\253'$'\254'$'\255'$'\256'$'\257'$'\260'$'\261'$'\262'$'\263'$'\264'$'\265'$'\266'$'\267'$'\270'$'\271'$'\272'$'\273'$'\274'$'\275'$'\276'$'\277'$'\300'$'\301'$'\302'$'\303'$'\304'$'\305'$'\306'$'\307'$'\310'$'\311'$'\312'$'\313'$'\314'$'\315'$'\316'$'\317'$'\320'$'\321'$'\322'$'\323'$'\324'$'\325'$'\326'$'\327'$'\330'$'\331'$'\332'$'\333'$'\334'$'\335'$'\336'$'\337'$'\340'$'\341'$'\342'$'\343'$'\344'$'\345'$'\346'$'\347'$'\350'$'\351'$'\352'$'\353'$'\354'$'\355'$'\356'$'\357'$'\360'$'\361'$'\362'$'\363'$'\364'$'\365'$'\366'$'\367'$'\370'$'\371'$'\372'$'\373'$'\374'$'\375'$'\376'$'\377'

(ich habe da einfach rm<space><tab> getippt, und die Expansion des
Namens, den ich nicht tippen will, der Shell überlassen)
Und weg is:

% ls
%


> Unter Windows sind die Regeln wohl etwas komplexer.

Ja. Einerseits, weil es mehr reservierte Zeichen gibt, die entweder gar
nicht oder nur an bestimmten Stellen vorkommen dürfen. Andererseits,
weil Filenamen in NTFS keine Byte-Strings sind, sondern UTF-16-Strings.

        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]

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

Am 31.08.2017 um 14:40 schrieb Hermann Riemann:
>
[...]
> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.

C definiert zu dem, was in einem Dateinamen erlaubt ist gar nichts.


Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

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

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

Am 31.08.2017 um 19:11 schrieb Thomas Orgelmacher:

>> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.

> C definiert zu dem, was in einem Dateinamen erlaubt ist gar nichts.

ANSI C und ältere Unix (Linux) waren "verheiratet".

Sprachen wie Ada, Java und Python
bauen ihre eigene Betriebssystem Umgebungen auf.
Wobei nach meiner Erfahrung fast alles Konflikte mit utf-8 hat(te).
( Erwartete 64 bit Konflikte habe ich bisher kaum bemerkt.)

Wobei manchmal seltsame Dinge entstehen wie:
https://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path

( dank SuSE bin ich ich praktisch an 3.4 (bei SuSE 42.3 immer noch)
   gebunden.)

Bei Python2 war pygame SDL gebunden.
Ob irgendwann bei Python3 und pygame (pygame2?) SDL2 aktiv wird,
habe ich nicht herausgefunden.
( pygame habe ich bisher nicht benutzt.
   SDL* in C bleibt wegen schneller Pixelmanipulation.
   Für einfache Grafiken könnte pygame interessant werden.)

Ach ja.
Die aus FORTRAN Zeiten stammende %s Darstellung
ist nach einer Messung in dieser Ecke schneller als {}
und nach meinem Eindruck auch besser lesbar;
aber ich vermute, dass bei Python 4? %s vielleicht
nicht mehr unterstützt wird.

Hermann
    gedanklich schon an ein Umsetzer
    Python3 Program ( mit tokenize ) denkend,
    welche z.B.
    os.system("rm ",filename) in os.unlink(filename) umwandelt.
-- 
http://www.hermann-riemann.de

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

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

Am 01.09.2017 um 09:12 schrieb Hermann Riemann:
> Am 31.08.2017 um 19:11 schrieb Thomas Orgelmacher:
> 
>>> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt.
> 
>> C definiert zu dem, was in einem Dateinamen erlaubt ist gar nichts.
> 
> ANSI C und ältere Unix (Linux) waren "verheiratet".

Bei älteren Unices war das wohl eher K&R. ANSI C gibt's AFAIK erst seit 1989.
Und Linux und Unix haben auf der Ebene generell nicht viel gemein.

Und "verheiratet"? Die sind in C geschrieben, ja. Und?

> Sprachen wie Ada, Java und Python
> bauen ihre eigene Betriebssystem Umgebungen auf.

Nein. Wie kommst Du darauf?

Ada definiert zwar ziemlich viel auf Sprachebene, aber AFAIK gehören Pfade
nicht dazu. Python hat pathlib. Aber von allein passiert da gar nichts.
Ebenso bei Java.

[...]
> ( dank SuSE bin ich ich praktisch an 3.4 (bei SuSE 42.3 immer noch)
>    gebunden.)

Python ist geradezu trivial zu kompilieren. Man kann da eigentlich nicht
viel falsch machen. Man kann natürlich auch auf den Distributor warten.

[...]> Ach ja.
> Die aus FORTRAN Zeiten stammende %s Darstellung

Und ich hätte schwören können, dass 'A' FORTRANs Formatierungsbezeichner für
Strings ist. Naja, ist lange her...

> ist nach einer Messung in dieser Ecke schneller als {}
> und nach meinem Eindruck auch besser lesbar;
> aber ich vermute, dass bei Python 4? %s vielleicht
> nicht mehr unterstützt wird.

Und wo kommt das her? Laut 3.7.0a0 ist der Operator noch nicht
einmal "deprecated".


Gruß, Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

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

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

Thomas Orgelmacher schrieb am 01.09.2017 um 21:06:
> Am 01.09.2017 um 09:12 schrieb Hermann Riemann:
>> aber ich vermute, dass bei Python 4? %s vielleicht
>> nicht mehr unterstützt wird.
> 
> Und wo kommt das her? Laut 3.7.0a0 ist der Operator noch nicht
> einmal "deprecated".

Python 4.0 wird wohl erst nach Python 3.9 erscheinen, was auch noch runde
vier Jahre hin ist, also so in 5-6 Jahren. Und Guido hat mehrfach geäußert,
dass Python 4 im Gegensatz zu Python 3 keine großen Kompatibilitätsbrüche
mit sich bringen soll.

Für letztere gibt es ohnehin die normalen Auslaufzeiten, also eine
"PendingDeprecationWarning" mit einem neuen Release, z.B. 3.7, dann eine
"DeprecationWarning" mit dem nächsten, z.B. 3.8, dann die Entfernung mit
dem darauf folgenden. "%"-Formatierung könnte also frühestens mit 3.9
entfernt werden. Ist aber unwahrscheinlich, weil der Bruch einfach zu groß
wäre. Die Konvertierung in ".format()" oder f-Strings lässt sich nämlich
auch nicht gut automatisieren, weil ja nicht immer über Literale formatiert
wird, und dahinter auch nicht immer erkennbare Tupel stehen. Also wage ich
mal zu orakeln, dass die "%"-Formatierung uns noch ein ganzes Weilchen
länger als die nächsten 5 Jahre erhalten bleiben wird. Trotz der hübschen
f-Strings.

Aber ich möchte auch orakeln, dass es zumindest Tools geben wird, die
Literale zur %-Formatierung und ".format()" in f-Strings konvertieren
können werden. Irgendwann schreibt das mal wer, vermutlich als 2to3-Fixer.
Könnte einige Leute glücklich machen.

Stefan

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

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

[Multipart message — attachments visible in raw view] — view raw

On Fri, 1 Sep 2017 21:06:11 +0200 Thomas Orgelmacher <trash@odbs.org>
wrote:
> [...]
> > ( dank SuSE bin ich ich praktisch an 3.4 (bei SuSE 42.3 immer noch)
> >    gebunden.)  
> 
> Python ist geradezu trivial zu kompilieren. Man kann da eigentlich
> nicht viel falsch machen. Man kann natürlich auch auf den Distributor
> warten.

Ich kann da pyenv und pyenv-installer
(https://github.com/pyenv/pyenv-installer) empfehlen. Da muss man sich
weder mit dem System-Python, noch dem Distributor rum ärgern.

- Arnold

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

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

On 30 Aug 2017, at 7:26, Hermann Riemann wrote:

> Am 29.08.2017 um 17:21 schrieb Walter Dörwald:
>
>> Python 3.6.2 (default, Jul 26 2017, 16:42:24)
>> Type 'copyright', 'credits' or 'license' for more information
>> IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.
>> In [1] ▶ base, revision, suffix = "foo", "bar", "baz"
>> In [2] ▶ %timeit base + revision + suffix
>> 208 ns ± 0.532 ns per loop (mean ± std. dev. of 7 runs, 1000000 
>> loops each)
>> In [3] ▶ %timeit '%s%s%s' % (base, revision, suffix)
>> 315 ns ± 1.55 ns per loop (mean ± std. dev. of 7 runs, 1000000 
>> loops each)
>> In [4] ▶ %timeit '{}{}{}'.format(base, revision, suffix)
>> 462 ns ± 1.23 ns per loop (mean ± std. dev. of 7 runs, 1000000 
>> loops each)
>> In [5] ▶ %timeit f'{base}{revision}{suffix}'
>> 14.6 ns ± 0.00911 ns per loop (mean ± std. dev. of 7 runs, 
>> 100000000 loops each)
>
> Daraus lese ich:
> a+b+c ist schneller als "%s%s%s"%(a,b,c),
> "%a%b%c"%(a,b,c) ist schneller als  "{}{}{}".format(a,b,c).
>
> Das mit 14.6 ns ist Hinweis,
> das in diesem Fall keine Zwischenwerte der Art (a+b)+c erstellt 
> wurden.

In [1] ▸ import dis
In [2] ▸ base, revision, suffix = "foo", "bar", "baz"
In [3] ▸ def f():
······ ▸     return f'{base}{revision}{suffix}'
······ ▸
In [4] ▸ dis.dis(f)
   2           0 LOAD_GLOBAL              0 (base)
               2 FORMAT_VALUE             0
               4 LOAD_GLOBAL              1 (revision)
               6 FORMAT_VALUE             0
               8 LOAD_GLOBAL              2 (suffix)
              10 FORMAT_VALUE             0
              12 BUILD_STRING             3
              14 RETURN_VALUE

BUILD_STRING ruft _PyUnicode_JoinArray() auf. Und _PyUnicode_JoinArray() 
berechnet einmal den Speicherverbrauch und kopiert dann alle Teile in 
den Zielspeicherbereich.

> Hermann
>    der jetzt wieder eher os.system("rm "+dateiname)
>    statt os.system("rm {}".format(dateiname)) schreiben wird.

Servus,
    Walter

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

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

Am 30.08.17 um 11:53 schrieb Walter Dörwald:
> On 30 Aug 2017, at 7:26, Hermann Riemann wrote:
> 
>> Am 29.08.2017 um 17:21 schrieb Walter Dörwald:
>>
>>> Python 3.6.2 (default, Jul 26 2017, 16:42:24)
>>> Type 'copyright', 'credits' or 'license' for more information
>>> IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.
>>> In [1] ▶ base, revision, suffix = "foo", "bar", "baz"
>>> In [2] ▶ %timeit base + revision + suffix
>>> 208 ns ± 0.532 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> In [3] ▶ %timeit '%s%s%s' % (base, revision, suffix)
>>> 315 ns ± 1.55 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> In [4] ▶ %timeit '{}{}{}'.format(base, revision, suffix)
>>> 462 ns ± 1.23 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> In [5] ▶ %timeit f'{base}{revision}{suffix}'
>>> 14.6 ns ± 0.00911 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops
>>> each)

Die konkrete Umsetzung ist bei Zeitmessungen immer wichtig.

Anstatt des Zugriffs auf die globalen Variablen:

%timeit '{}{}{}'.format(base, revision, suffix)
421 ns ± 4.23 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

die Anfangswerte direkt mit %%time zu setzen:

%%timeit base, revision, suffix = "foo", "bar", "baz"
'{}{}{}'.format(base, revision, suffix)
367 ns ± 5.77 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

bringt hier ähnliche Ergebnisse.

Aber für die Variante mit f-String sieht das anders aus:

%timeit f'{base}{revision}{suffix}'
14.1 ns ± 0.127 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

%%timeit base, revision, suffix = "foo", "bar", "baz"
f'{base}{revision}{suffix}'
98.6 ns ± 2.02 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

Die letzte Variante scheint mir die realistischere Variante zu sein.
In der schnelleren Variante ist wahrscheinlich Caching im Spiel.

Schlussfolgerung: f-Strings sind immer noch schneller, aber halt nicht gleich
mehr als eine Größenordnung sondern eher um den Faktor 3-4.

Mike

>>
>> Daraus lese ich:
>> a+b+c ist schneller als "%s%s%s"%(a,b,c),
>> "%a%b%c"%(a,b,c) ist schneller als  "{}{}{}".format(a,b,c).
>>
>> Das mit 14.6 ns ist Hinweis,
>> das in diesem Fall keine Zwischenwerte der Art (a+b)+c erstellt wurden.
> 
> In [1] ▸ import dis
> In [2] ▸ base, revision, suffix = "foo", "bar", "baz"
> In [3] ▸ def f():
> ······ ▸     return f'{base}{revision}{suffix}'
> ······ ▸
> In [4] ▸ dis.dis(f)
>   2           0 LOAD_GLOBAL              0 (base)
>               2 FORMAT_VALUE             0
>               4 LOAD_GLOBAL              1 (revision)
>               6 FORMAT_VALUE             0
>               8 LOAD_GLOBAL              2 (suffix)
>              10 FORMAT_VALUE             0
>              12 BUILD_STRING             3
>              14 RETURN_VALUE
> 
> BUILD_STRING ruft _PyUnicode_JoinArray() auf. Und _PyUnicode_JoinArray()
> berechnet einmal den Speicherverbrauch und kopiert dann alle Teile in den
> Zielspeicherbereich.
> 
>> Hermann
>>    der jetzt wieder eher os.system("rm "+dateiname)
>>    statt os.system("rm {}".format(dateiname)) schreiben wird.
> 
> Servus,
>    Walter
> _______________________________________________
> python-de maillist  -  python-de@python.org
> https://mail.python.org/mailman/listinfo/python-de

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

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

Am 25.08.17 um 10:28 schrieb Tobias Herp:

> Dann erfüllt die "Variante 3" den Zweck:
> 
> d = ''.join([a, b, c])
> 
...

> Die "Variante 3" konvertiert Nicht-Strings stillschweigend. Was aber, wenn ich ganz selbstverständlich davon ausgehe, daß es Strings sind, und eine Abweichung hiervon ein sicheres Zeichen für einen Fehler ist? Ich verplempere nicht nur eine Menge Rechenzeit, sondern verberge auch noch den Fehler:

Das stimmt aber nun nicht:

>>> ''.join(['a', 2])
TypeError    Traceback (most recent call last)
''.join(['a', 2])
TypeError: sequence item 1: expected str instance, int found

Mike

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

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

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

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

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

Mike Müller schrieb am 25.08.2017 um 11:18:
> Am 25.08.17 um 10:28 schrieb Tobias Herp:
> 
>> Dann erfüllt die "Variante 3" den Zweck:
>>
>> d = ''.join([a, b, c])
>>
> ...
> 
>> Die "Variante 3" konvertiert Nicht-Strings stillschweigend.

Ok, hier ist mir ein Tippfehler unterlaufen; es sollte "Variante 2"
heißen und trifft auf jede Template-Variante zu, egal ob als '{}'.format
oder '%s' % ...

>> Was aber, wenn ich ganz selbstverständlich davon ausgehe, daß es
Strings sind, und eine Abweichung hiervon ein sicheres Zeichen für einen
Fehler ist? Ich verplempere nicht nur eine Menge Rechenzeit, sondern
verberge auch noch den Fehler:
> 
> Das stimmt aber nun nicht:
> 
>>>> ''.join(['a', 2])
> TypeError    Traceback (most recent call last)
> ''.join(['a', 2])
> TypeError: sequence item 1: expected str instance, int found

Das Verplempern von Rechenzeit bezog sich auch nicht auf die join-,
sondern auf die grausliche .format-Variante ...

Was Du ausprobiert hast, ist genau, was ich meine: wenn der join-Aufruf
erfolgreich war, waren auch alle Argumente korrektermaßen Strings.
Ansonsten wurde möglicherweise die aktuelle Funktion falsch aufgerufen,
und die implizite Konversion würde den Fehler verbergen, der sich
ansonsten durch den TypeError bemerkbar machen würde.

-- 
Tobias

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

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

Servus Hermann!

Am 25.08.2017 um 07:45 schrieb Hermann Riemann:
> d=a+b+c besser als
> d="{}{}{}".format(a,b,c) ?
Es gibt gute Gründe, warum es mehrere Formulierungen gibt um Strings zu
addieren. Jede Formulierung hat Ihre Vor- und Nachteile, und keine ist
sinnlos. Lies die Doku oder frage hier konkreter nach einer Lösung.

Es gibt keine beste Lösung per se.

Beste Grüße

Volker



-- 
=========================================================
   inqbus Scientific Computing    Dr.  Volker Jaenisch
   Richard-Strauss-Straße 1       +49(08861) 690 474 0
   86956 Schongau-West            http://www.inqbus.de
=========================================================

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

#4874

Am 25.08.2017 um 07:45 schrieb Hermann Riemann:
> Was ist besser?
> a b und c enthalten strings.
> 
> d=a+b+c besser als
> d="{}{}{}".format(a,b,c) ?

In diesem Fall ist das fast egal. Auch die Performance wird nahezu
identisch sein. Ich würde den + Operator bevorzugen.

Was man nicht machen sollte ist eine Konstruktion wie

s = ''
for i in range(1000):
     s = s + 'x'

Hier wird 1001 mal ein str instantiiert und 1000 müssen vom CG wieder
entsorgt werden.

Da wäre ein ''.join(['x' for i in range(1000)]) deutlich effektiver.
Ja, ich weiß. 'x' * 1000 wäre noch besser, aber es ging ja nur ums
Beispiel.


Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

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

#4880

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Thomas Orgelmacher <trash@odbs.org> writes:
>>Am 25.08.2017 um 07:45 schrieb Hermann Riemann:
>>>d=a+b+c besser als
>>>d="{}{}{}".format(a,b,c) ?
>>In diesem Fall ist das fast egal.
> ...
>>Ich würde den + Operator bevorzugen.
>
>   Das kann ich beides unterstreichen!
>
>   Wenn etwas lesbar genug ist, dann lohnt es sich
>   nicht mehr, sich zu überlegen, was "lesbarer" ist.

Es lohnt sich aber, zu überlegen, ob es wirklich das ausdrückt was man
sagen will -- explizit ist besser als implizit.

Zusammenfügen von n Strings (mit n=3):
 s = a + b + c
Bildung eines neuen String mithile eines (trivialen) Templates:
 s = "{name}{md5}{suffix}".format(name=a, md5=b, suffix=c)

>   Kann jemand bei der folgenden Eingabe sofort erkennen, ob
>   die Anzahl der »{}« gleich der Anzahl der Variablen ist?
>
> "{}{}{}{}{}{}{}{}{}{}".format( a, b, c, d, e, f, g, h, i, j )

Das geht davon aus, dass die Bildungsvorschrift (Concatenieren) fix ist
und die Zahl der Argumente prinzipiell variabel.

Was der OP so nicht formuliert hat.

>   Kann ich als Wartungsprogrammierer jetzt ohne weiteres wissen,
>   ob der Werte dieses letzten Ausdrucks so beabsichtigt war?
>   Ob das »j« vielleicht gelöscht werden oder ein »{}«
>   hinzugefügt werden soll?

Schreibe die Semantik dazu (explizit besser als implizit), und es wird
sofort klar.

>   (Brille aufsetzen!)? Solche Fragen treten bei
>
> a + b + c + d + f + g + h + i + j
>
>   nicht auf

Richtig. Da wird nämlich gar nicht auffallen, dass das "e" fehlt.
(Sorry fürs Zitatfälschen)

Ole

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

#4907

On 2017-08-29 17:05, Thomas Orgelmacher <trash@odbs.org> wrote:
> Was man nicht machen sollte ist eine Konstruktion wie
>
> s = ''
> for i in range(1000):
>      s = s + 'x'
>
> Hier wird 1001 mal ein str instantiiert und 1000 müssen vom CG wieder
> entsorgt werden.
>
> Da wäre ein ''.join(['x' for i in range(1000)]) deutlich effektiver.
> Ja, ich weiß. 'x' * 1000 wäre noch besser, aber es ging ja nur ums
> Beispiel.

Wenn es Dir nicht ums Beispiel geht, dann hast Du wahrscheinlich nicht
1000 mal den gleichen String sondern 1000 verschiedene Strings. 

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

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

        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]

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

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

csiph-web