python-de August 2017

python-de@python.org

11 participants
9 discussions

Berliner PUB-/DZUG-Treffen am 17.9. um 19 h im newthinking store
by Dinu Gherman 04 Sep '22

04 Sep '22

Liebe Python-Freunde, diesen Donnerstag, den 17.8.2009 (übermorgen!) findet wieder ein PUB/DZUG-Treffen (Python und Zope User Group in Berlin) statt. Ort und Zeit sind wie immer: 19 Uhr, im newthinking store [1]. Anschließend wird das Treffen wieder im Restaurant Tucholsky [2] fortgesetzt. Zur Planung der Restaurantkapazitäten bitte ich euch ein Häckchen in der Doodle-Umfrage [3] zu machen, wenn ihr an- schließend noch mitkommen wollt. Das Programm muss dieses mal etwas kurzfristig arrangiert werden. Wer also schon immer mal einen kurzen Vortrag halten wollte, z.B. zu einem der Themen im Python-Wiki [4] und diesen womöglich schon in der Schublade hat, der (oder die) ist herzlich dazu eingeladen. Dann bitte bei mir vorher kurz per E-Mail ankündigen! Ansonsten werden einige, die auf der DZUG-Tagung letzte Woche in München waren, locker darüber berichten. Dabei ging es unter an- derem über die kommenden Versionen 4 und 5 von Plone. Sehr wahr- scheinlich wird Veit dazu Prospekte verteilen. Eine weitere Idee besteht darin, locker Buchempfehlungen zu den Themen Python/Zope/Plone auszutauschen, was man am besten macht, indem man das jeweilige Buch auch zum Treffen mitnimmt. Ich werde am Donnerstag das Buch "Python for Linux and Unix System Admini- stration" [5] dabei haben. Liebe Grüße und bis Donnerstag, Dinu PS: Ich übernehme mit Veit bis auf Weiteres die Organisation die- ser Treffen von Stephan, der das bisher vorbildlich gemacht hat, aber nun seinen väterlichen Aufgaben höhere Priorität geben wird. Nochmals vielen Dank, Stephan - ich hoffe, Du kannst trotzdem noch vorbeischauen! [1] newthinking store, Tucholskystr. 48, 10117 Berlin, http://newthinking-store.de [2] Restaurant Tucholsky, Torstraße 189, 10115 Berlin, http://www.restauration-tucholsky.de [3] http://doodle.com/rwqizz6ewxk6iscw [4] http://wiki.python.de/User%20Group%20Berlin [5] http://www.oreilly.de/catalog/9780596515829 ...................................................................... Follow me on Twitter: http://twitter.com/dinugherman

2 1

strings zusammensetzen.
by Hermann Riemann 16 Sep '17

16 Sep '17

Was ist besser? a b und c enthalten strings. d=a+b+c besser als d="{}{}{}".format(a,b,c) ? Hermann der hier nicht an Lesbarkeit denkt. -- http://www.hermann-riemann.de

8 13

Re: [Python-de] strings zusammensetzen.
by Hermann Riemann 02 Sep '17

02 Sep '17

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

5 6

Re: [Python-de] strings zusammensetzen.
by Hermann Riemann 31 Aug '17

31 Aug '17

Am 30.08.2017 um 07:48 schrieb Stefan Behnel: > Übrigens, da es gerade um Geschwindigkeit ging - ich wette, mit > os.system("rm "+dateiname) > kannst du die Datei deutlich schneller löschen als mit > os.system("rm {}".format(dateiname)) > oder gar mit > os.unlink(dateiname) Die zeitlichen Unterschiede dürften meist gering sein. Hermann der wegen des Lernaufwandes und Manual Suchens lieber os.system("rm "+dateiname) als os.unlink(dateiname) verwendet. -- http://www.hermann-riemann.de

5 9

Re: [Python-de] strings zusammensetzen.
by Hermann Riemann 30 Aug '17

30 Aug '17

Am 30.08.2017 um 10:23 schrieb Peter Otten: >> daher ist er auf kate (ohne ~) ausgewichen.) > "ohne ~"? Versteh ich nicht. emacs und xemacs erzeugen beim Editieren Kopien der Originaldateien, deren Dateiname aus Originaldateiname mit angehängtem '~'-Zeichen bestehen. Hermann der mit seinem Löschprogramm für Dateien mit ~ am Ende auch *.pyc Dateien löschen kann. -- http://www.hermann-riemann.de

1 0

Re: [Python-de] strings zusammensetzen.
by Hermann Riemann 30 Aug '17

30 Aug '17

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. Hermann der jetzt wieder eher os.system("rm "+dateiname) statt os.system("rm {}".format(dateiname)) schreiben wird. -- http://www.hermann-riemann.de

4 3

Re: [Python-de] strings zusammensetzen.
by ole-usenet-spam＠gmx.net 30 Aug '17

30 Aug '17

ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Thomas Orgelmacher <trash(a)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

1 0

Re: [Python-de] strings zusammensetzen.
by ole-usenet-spam＠gmx.net 29 Aug '17

29 Aug '17

"Tobias Herp" <tobias.herp(a)gmx.de> writes: >>> 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! Das hängt IMO stark vom Use-Case ab. Oft hat man z.B. solche String-Concatenierungen im Zusammenhang mit der Erstellung von Dateinamen. Und da wäre es besser, ein Template zu verwenden -- genau im Sinne von "explizit ist besser als implizit": d = "{base}{revision}{suffix}".format(base = a, revision = b, suffix = c) Allgemein würde ich, wenn es sich um Strings handelt, immer genau schauen, ob man nicht eigentlich ein Template füllen möchte, das nur gerade zufällig sehr einfach ausfällt. Schöne Grüße Ole

4 3

Re: [Python-de] strings zusammensetzen.
by ole-usenet-spam＠gmx.net 26 Aug '17

26 Aug '17

Tobias Herp <tobias.herp(a)gmx.de> writes: > Оlе Ѕtrеісhеr schrieb am 25.08.2017 um 10:47: >> "Tobias Herp" <tobias.herp(a)gmx.de> writes: >>>>> 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! >> >> Das hängt IMO stark vom Use-Case ab. Oft hat man z.B. solche >> String-Concatenierungen im Zusammenhang mit der Erstellung von >> Dateinamen. Und da wäre es besser, ein Template zu verwenden -- genau im >> Sinne von "explizit ist besser als implizit": > > Nur dadurch, daß etwas umständlich programmiert ist, wird es noch nicht > expliziter. Und umständlich ist es, wenn man zum Hinzufügen einer > weiteren Variablen zwei Änderungen vornehmen muß. Das hängt eben von der Anwendung ab. Wenn die Aufgabe war, "n gleichwertige Strings concatenieren mit dem Spezialfall n=3", hast Du recht. Wenn die Aufgabe ist "einen String aus semantisch unterschiedlichen Strings nach einer bestimmten Regel erzeugen (und die Regel ist erstmal die einfache Aneinanderfügung)", dann ist format() besser. In diesem Fall ist auch klar, dass eine Erweiterung typischerweise zwei Änderungen erfordert: einmal muss die Regel selbst geändert werden, und dann muss man natürlich die zugehörigen Daten zur Verfügung stellen. >> d = "{base}{revision}{suffix}".format(base = a, >> revision = b, >> suffix = c) > > Wenn's denn unbedingt ein Template sein soll, würde das bei mir meistens > wie folgt aussehen: > > d = '%(base)s%(revision)s%(suffix)s' % locals() Warum sollte man die veraltete Form mit "%" verwenden? > (natürlich nennt *niemand* seine Variablen a, b und c, bzw. würde es > nach Lektüre dieses Threads niemals zugeben...) a, b und c habe ich hier als Platzhalter interpretiert, nicht notwendig als Variablen. > Im übrigen kann es natürlich jedem Stück Code in einem größeren Projekt > (oder in einer Server-Anwendung) passieren, daß es sehr oft durchlaufen > wird. Und spätestens dann spielt die Performanz eine Rolle. Die > .format-Methode bezahlt für ihre (ich behaupte: in mindestens 95% der > Fälle nicht benötigte) zusätzliche Flexibilität mit sehr viel > schlechterer Performanz. Man sollte nicht zu früh optimieren, und Lesbarkeit geht häufig über Effizienz. In dem von mir gebrachten Beispiel (Generierung eines Dateinamens): Nach der Bildung eines Dateinamens erfolgt fast immer eine I/O-Operation mit dieser Datei, und die ist viel langsamer als jede String-Format-Operation. Und zwar selbst dann, wenn sie "irgendwann" mal in einer Server-Anwendung läuft. >> Allgemein würde ich, wenn es sich um Strings handelt, immer genau >> schauen, ob man nicht eigentlich ein Template füllen möchte, das nur >> gerade zufällig sehr einfach ausfällt. > > Man kann es auch übertreiben mit der vorausschauenden Komplexität. > Wie heißt es doch so schön - YAGNI! > You ain't gonna need it! Man sollte sich einfach Gedanken um seinen Code machen, bevor man ihn schreibt. Gerade im Fall der Generierung von Dateinamen habe ich zu Anfang häufig einfach Strings concateniert, und (weils so einfach ist) das auch noch gleich lokal da, wo ichs brauchte. Wenn dann jemand kam und einen zusätzlichen Bindestrich drin haben wollte, habe ich geflucht und alle Stellen, wo ich den Dateinamen zusammengebaut habe, wieder herausgesucht und geändert. Ein (gemeinsames) Template für diese Stellen vermeidet das bei mir in neueren Projekten, selbst wenn das meist erstmal so aussieht wie oben (und damit einfach drei Strings concateniert). Schöne Grüße Ole P.S. Ich brauche keine Mailkopie.

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

python-de August 2017